Every tool on this site runs in your browser. There is no upload, no account and no server that sees your JSON, and this post explains how that works, how to check it yourself rather than trust it, and what the tools deliberately do not do.
What happens when you paste
When you open a tool page, your browser downloads an HTML page and a small JavaScript file. That is the whole tool. When you paste a document and press a button, the parsing and printing happen inside the tab, and the result is written back into the page. Nothing is sent anywhere, because there is nowhere to send it: the site has no backend for tool data at all.
That also means nothing is stored. Close the tab and the document is gone. There is no history to clear, no account to delete and no cache holding your data. The site does keep two small values in your browser, your theme choice and your answer to the cookie notice, and both stay on your device.
Check it yourself in thirty seconds
Any privacy claim you cannot verify is just a sentence on a page. This one takes half a minute to test:
- Open any tool, for example the formatter.
- Open your browser developer tools and switch to the Network tab.
- Clear the list, paste some JSON, and press Format.
Nothing new appears in the list, because no request is made. Compare that with a tool that posts to an endpoint when you press its button, which you will see immediately in the same panel.
There is one deliberate exception, and it is on a different page: the contact form does send what you type into it, since a message that stays in your browser is not a message. Everything else stays local.
The project also asserts this automatically. The end to end test suite pastes a unique marker into each tool, runs it, and fails the build if that marker appears in any request the page makes. That test runs on every build, so the claim cannot quietly rot the next time somebody adds a feature.
Why the tools read tokens instead of parsing
Most online formatters do something like this internally:
JSON.stringify(JSON.parse(input), null, 2)It looks harmless and it corrupts data in two specific ways.
Long integers lose precision. JavaScript numbers are doubles, so an integer
longer than about sixteen digits cannot be held exactly. Paste
{"id": 12345678901234567890} into a formatter built that way and you get
12345678901234567000 back. Nothing warns you.
Integer looking keys get reordered. JavaScript objects order integer like
keys numerically, ahead of everything else. So {"2": "silver", "1": "gold"}
comes back as {"1": "gold", "2": "silver"}, which matters whenever the order
was meaningful, and it often is in a config file.
The tools here never build a JavaScript value from your document. They tokenise it, keeping the exact source text of every token, and reprint the token stream with different whitespace. Your document comes back byte for byte as you wrote it, with only the spacing changed. Unit tests lock both cases in, so a future refactor cannot reintroduce either.
The same decision runs through the rest of the site. The viewer shows the text you actually wrote next to each key. The diff will not call two twenty digit integers equal just because they collapse onto the same double. The pointer evaluator hands back the exact source of the value it resolved.
Why the error messages are the way they are
A validator that says “unexpected token” has told you nothing you did not already know. Most of the work in the parser here went into the messages instead. A trailing comma is reported as a trailing comma. An unclosed bracket is reported against the line where the bracket was opened, not the end of the file. A wrong case keyword suggests the lower case spelling. A duplicate key produces a warning with both line numbers rather than silence.
If you want the catalogue, the post on common JSON syntax errors walks through the nine that come up most, with the edit that fixes each.
What the site does not do
Some standards here are implemented in part. The JSONPath tester supports the selectors that real queries use and lists them on the page. Function extensions and a few other corners of RFC 9535 are missing, and using one produces a message naming the feature rather than a vague failure. JSON Pointer is the opposite case: RFC 6901 is four pages, so all of it is implemented.
Repair can change your data. NaN, Infinity and undefined have no JSON
equivalent, so the repair tool turns them into null and lists
those changes separately from the punctuation fixes. Read that list rather than
trusting the output.
Very large documents degrade on purpose. Above roughly two hundred thousand characters, syntax colouring switches off so typing stays smooth, and the page says so when it happens. The viewer draws a branch only when you open it, and past a few thousand values it refuses to expand everything at once rather than freezing the tab for a minute.
Where to start
If you arrived with a broken document, the validator will tell you what is wrong with it and the repair tool will fix the mechanical parts. If you arrived with a working document you do not understand, the viewer is the fastest way in. Everything else is on the tools page.