Developer tools

The small operations that interrupt an afternoon: a JWT that has to be read, a payload that has to be legible, a string that has to survive a query parameter. Every tool here runs inside the page you are on, which is the point — the strings a developer pastes into a site like this are routinely the ones that should never have left the machine.

19 tools

JSON formatterSomebody handed a wall of JSON on one line — an API response, a log field, a config blob — who needs to see its structure before they can do anything with it.
Base64 decodeSomebody holding a string of apparent gibberish that they need to read — a JWT payload, a value out of a Kubernetes secret, a log line, an attachment header — and who wants to know what is in it without giving it to a stranger.
Unix timestamp converterSomebody looking at a ten- or thirteen-digit number in a log, a database column or a JSON payload, who needs to know what moment it refers to and in which zone.
JSON validatorSomebody whose JSON is being rejected by something that will not say why, who needs the line and column of the first thing wrong with it.
Base64 encodeSomebody who has to put a string somewhere that will not accept it as it stands — a data URI, a Basic auth header, a JSON field that has to survive a transport with opinions about which bytes are allowed.
SHA-256 hash generatorSomebody who needs a SHA-256 of a piece of text — an integrity value, a fingerprint to compare, a deterministic identifier — and wants the current, unbroken answer.
URL encodeSomebody assembling a URL by hand — a query parameter with a space or an ampersand in it, a redirect target that has to survive being a value inside another URL — who needs to know which characters have to be escaped and which must not be.
UUID generatorSomebody who needs one or several identifiers right now — for a fixture, a migration, a config file, a test — and does not want to open a terminal to get them.
MD5 hash generatorSomebody who needs an MD5 of a piece of text — to compare against a value in a database, to reproduce a cache key, to check a legacy integration that still uses it.
URL decodeSomebody reading a URL out of a log, an analytics report or an error message, where the interesting part is buried under percent sequences and has to be turned back into something legible.
HTML encodeSomebody putting text they did not write into a page — a comment, a product description, an example of markup — who needs the characters that would otherwise become tags to stay characters.
HTML decodeSomebody looking at text that was escaped once too often — a title full of ampersand-amp, an RSS item, a column exported from a CMS — who needs to see what it originally said.
JSON minifierSomebody who has to put JSON somewhere that a formatted document will not fit or will not survive — an environment variable, a single log line, a request body they are trying to shrink.
SHA-1 hash generatorSomebody who has to produce a SHA-1 because something else requires one — a Git object, an old API signature, a legacy integration — rather than because they chose it.
URL parserSomebody holding an address that is behaving unexpectedly — a redirect that lands somewhere odd, a link with a port in it, an address with two question marks — who needs to see how a browser reads it.
Hex encodeSomebody who needs to see or supply the actual bytes of a string — a protocol field, a test fixture, a key in documentation, a value that has to be typed into a hex editor.
Hex decodeSomebody holding a run of hexadecimal digits out of a log, a packet capture or a debugger, who wants to know whether it is text and what it says.
Query string parserSomebody reading a long query string out of an analytics export, a log line or a tracking link, who needs the parameters listed and decoded rather than run together.
UUID validatorSomebody holding an identifier that something rejected, who needs to know whether it is a well-formed UUID at all and which version and variant it claims to be.

Why a developer tool being local is not a preference

The things people paste into an online Base64 decoder are, in order of frequency: a JWT, a Basic auth header, a webhook payload and a config file. Three of those four are credentials or contain them. A site that decodes them on a server has, by construction, seen them — and has them in its request logs whether or not anybody meant to keep them.

That is not a hypothetical objection to a hypothetical risk. It is why several companies block this whole class of site at the proxy, and why the ones that do not usually have a policy nobody reads. Everything on this page is arithmetic a browser can do; running it anywhere else is a choice, and it is the wrong one.

What "runs in your browser" means here, precisely

The page is static HTML delivered from a CDN. When you press a button, a small JavaScript module is fetched — once, and cached — and the work happens in your tab. No request carries what you typed, and you can confirm that in the network panel rather than taking our word for it.

Two honest qualifications. The page itself is a request, so the fact that you visited it is visible to us and to your network. And the site carries advertising and, if you accept it, analytics — neither of which can see the contents of a text box, but both of which are third-party requests. The distinction is between what you type and the fact that you are here; the first never moves, the second unavoidably does.

One tool per question, not one tool with a dropdown

A single page that encodes and decodes Base64, URLs and HTML behind a selector is fewer pages and worse. Encoding and decoding fail differently, are explained differently, and are searched for differently — the person with a broken percent-sequence and the person building a query string have almost nothing to say to each other.

So each direction gets its own page, with the failure modes that belong to it: what to do when Base64 decodes to bytes that are not text, why `encodeURIComponent` leaves an exclamation mark alone and what that does to an OAuth signature. That is a page worth reading, and it is only possible because it is not trying to serve six audiences at once.

They work with the network off

Once a tool page has produced its first answer, everything it does is local, so it keeps working on a plane, on a train, and behind a corporate proxy that blocks the site an hour after you loaded it. The engine is a second, small download: on most of these pages it arrives and runs the moment the page opens, and on the UUID generator, which waits for its button, it arrives on the first press. There is no service worker and nothing is installed — it is simply that a page which never calls out has nothing to lose when the connection does.

The practical consequence is that these are usable in the situations where an online tool is normally exactly wrong: on a machine that is not yours, on a network you do not trust, with data you should not be moving. That is the case they were built for.

Developer tools: common questions

Is anything I paste sent to a server?

No. Every tool in this section computes in the page, and the network panel is the way to check rather than a claim to believe. The page itself is fetched from a CDN and the site carries ads, so requests do happen — none of them carries the contents of a text box.

Is there a limit on how much text I can paste?

Only what your own machine will hold. Nothing is queued, metered or counted, because there is no server doing the work that could meter it. Very large inputs will make the browser tab work for a moment, which is the only ceiling there is.

Do I need an account?

No, and there is nothing to sign up for. The tools do not save anything between visits either — closing the tab is what deletes your input, because the input never existed anywhere but the tab.

Can I use these on work data?

That is a question for your own policy, but the technical answer is that the data does not leave your device, which is normally the part such a policy is about. If you need to demonstrate it rather than assert it, open the network panel while you use the tool: there is nothing to show.

Why is there no dark-pattern download step?

Because there is no file. The result is text on the page, ready to select or copy, and there is nothing to gain by making you press an extra button first. Where a tool does produce a file — an image, for instance — the download is the last step rather than a gate in front of the answer.