← Home

The short version

1234.nu is my self-hosted box of small developer tools and browser games, all under one roof, with no sign-up, no accounts, and no tracking. Open a tool, use it, close the tab. Nothing about you is built up over time.

How this site came to be

I registered this domain several years ago with exactly this in mind: one big toolbox where every small utility a developer reaches for lives in one place, without the ads, sign-ups and trackers that plague most tool sites. The design and the architecture were also drawn up a long time ago. Small self-contained tools, one shared core, everything served from a single origin. What was missing was time. Building hundreds of tools by hand, evenings and weekends, simply did not scale.

That changed with agentic coding. The site is now built in an agentic workflow with Anthropic's Claude Code, and the implementation of that old design went faster than I ever managed by hand. The architecture, the conventions and the security rules are all mine and were set long before the agent showed up. The agent works inside those rails and fills in the toolbox, tool by tool.

How a tool gets built here

The workflow is a loop, and you are part of it. Every page has a button. Bug reports and feature requests land in a small backend on the server, and that queue is where most work starts. When I sit down to work on the site, the agent reads the open feedback, groups it into a batch, and implements it item by item under my review.

Two things make that reliable. First, skills: reusable, written-down procedures the agent follows for recurring jobs, like adding a new tool, resolving a feedback batch, or shipping a change. A skill encodes the house rules once, so every new tool comes out with the same structure, the same rate limiting and the same privacy defaults instead of depending on memory or mood. Second, a vault of markdown notes: the project keeps its own long-term knowledge as a folder of small, linked documents, one concept per file, in the same style as an Obsidian vault. It holds the architecture, the design decisions and a page per tool. The agent reads it before it works and updates it after, so lessons learned on tool number 50 still hold on tool number 350.

Shipped feedback shows up in the footer: the changelog lists what went out in every build, and resolved feedback items are marked as done. If you reported it, you can see it land.

Why no cookies and no tracking

This part came first, before any tool was written, and it is personal. I got tired of what the web has become: consent banners on every visit, trackers behind every button, and "free" tools that pay for themselves with your data. I did not want to be tracked, so I was not going to track anyone else. That was the deal I made with myself when I registered the domain.

There is a practical side too. Developer tools get fed sensitive things: tokens, passwords, private JSON, internal URLs. A tool you cannot trust with those is useless, and trust here should not require taking my word for it. So the site is built to be verifiable: most tools run entirely in your browser, every tool page carries a chip saying where your data is processed, and you can open your browser's developer console on any client-side tool and watch the network tab to confirm that nothing leaves your machine. All the code that runs is served from this site and readable right there.

And honestly, not collecting anything keeps life simple. No accounts means no passwords to protect, no profiles to leak, no consent banner to bolt on. What does not exist cannot be stolen.

Most tools run entirely in your browser

The majority of the tools here are fully client-side. When you open something like the JSON formatter, the hash generator, the QR maker, the image converter or any of the games, the server's only job is to hand your browser the page. After that, all the work happens locally on your device. Your input is processed by JavaScript running in the tab and is never sent anywhere.

Concretely, that means the text you paste, the files you drop, the passwords or secrets you generate, and the photos you inspect never leave your machine when the tool is client-side. There is no upload happening behind the scenes, and the privacy chip under the navigation tells you which kind of tool you are on before you type a thing.

A few tools do talk to the server, and they say so

Some things genuinely cannot be done in the browser, so a smaller set of tools send data to the server to do their job:

Where a tool sends or stores data, its description, its page and its privacy chip say so plainly. The rule of thumb: if a tool's whole point is to produce a link or reach the network, it uses the server; otherwise it does not.

How it's put together

Under the hood it is one small Node.js app. Each tool is a self-contained module with its own page and its own logic, and tools do not share state or reach into each other. There is no per-user database, no session, no profile. The only things the server keeps are the items you explicitly create with the share and store tools (with their expiry) and a set of aggregate, anonymous visit counters. The privacy page spells out exactly what those are.

Built to be safe by default

Open about what runs

Stateless tools are also exposed over a plain REST API and an MCP endpoint, so you can script them or wire them into a client like Claude. The footer always shows the current build, with the full changelog one click away.

Want the privacy specifics, like what the visit counters store and how long anything is kept? That is all on the privacy page.

Send feedback

How this works

Stores only this report's id in your browser (localStorage) so a small note can pop up here once it ships. No account, nothing sent to us, no tracking. Clearing this site's data forgets it.

Changelog

What changed, and when. Newest first.

Loading…