Free Developer Tools

Utilities, not a platform

Every developer keeps a mental list of ten-second jobs: decode this token so you can read the claims inside it, pretty-print a response body that arrived as one long line, generate an identifier for a test fixture, encode a value so it survives a query string. None of them are hard. All of them are annoying when the tool you reach for wants an account first.

These pages are the opposite of a platform. Each one is a single static HTML file with the logic inlined. There is no login, no dashboard, no history, no usage tier, and no upsell. Open it, do the thing, close it.

Why running locally matters more here

For most categories on this site, client-side processing is a nice privacy property. In developer tooling it is closer to a requirement. The values you paste into an encoder or a formatter are disproportionately likely to be sensitive: bearer tokens, signed payloads, connection strings, customer records that happen to be in the response you are debugging.

A conventional online formatter posts all of that to a backend. Even a well-run one will have it in an access log. A badly-run one — and you cannot tell which you are using from the outside — may keep it indefinitely. There have been enough incidents of exactly this kind that many teams now ban the whole category of site outright.

You can confirm our behaviour rather than trusting it. Open your browser's developer tools, switch to the network tab, and use any tool on this site. After the initial page load you will see no further requests. The processing is happening in the same JavaScript context as the page you are looking at.

Correctness details we care about

Small utilities fail in small ways that cost real time. Base64 encoders built on the browser'sbtoa throw an exception on any character outside Latin-1, so an accented name or an emoji breaks them — ours encodes to UTF-8 bytes first, so any text round-trips. Decoders frequently accept malformed input and return mojibake instead of an error; ours decodes strictly and tells you when the input is not valid Base64 rather than handing back plausible nonsense.

Where a spec allows more than one behaviour, the tool page says which one it implements and gives you the switch. That is more useful than a tool that silently picks for you and leaves you wondering why two systems disagree.

Linking to these pages

You are welcome to link to any of these tools from documentation, a README, a Stack Overflow answer or an internal wiki. The URLs are stable and will not move. Because there is no account wall, whoever follows the link lands directly on a working tool rather than a signup form, which is usually the point of sharing it.

What is coming next

The queue for this category follows what people actually search for rather than what is interesting to build: a JSON formatter and validator, JSON to CSV in both directions, URL encoding, UUID generation in bulk, hash digests, and a JWT decoder that splits the three segments out and pretty-prints the claims.

Each one ships only when it handles the awkward cases properly — malformed input, very large payloads, Unicode outside the ASCII range — because a developer tool that is right ninety percent of the time costs more than it saves. If something you use constantly is missing,say so; requests move things up the queue.