About the JSON Formatter
JSON is the format almost every API speaks, and almost none of them return it in a shape a human can read. This tool takes a wall of minified output, or a config file you have been editing by hand, and either expands it into indented form or collapses it back down. If the document has a syntax error it tells you the line and column, and names the mistake rather than making you infer it.
Everything happens in your browser. The text you paste is never uploaded, logged, or sent to a server, which matters because the JSON people most often need to inspect is a live API response containing a token, a customer record, or an internal identifier.
How to use this tool
- Paste or type your JSON into the box. It is checked as you type, and your text is never rewritten while you are editing it.
- Watch the strip below the box. It reads Valid JSON, or gives you the line, the column, and what went wrong.
- Choose an indent width - two spaces, four spaces, or a tab - if you plan to format.
- Press Format to expand the document, or Minify to strip every byte of insignificant whitespace. Both rewrite the box in place, so you can press either repeatedly without stacking changes.
- Press Copy to put the result on your clipboard, or Clear to start again.
Why the error points at a different line than you expect
A JSON parser reports where it gave up, not where you made the mistake. Those are often far apart. Forget a closing brace on line 4 of a 200-line document and the parser happily keeps consuming properties until it hits the end of the file, so the error lands on line 200 with a message about unexpected end of input. The mistake is nowhere near there.
The useful way to read the caret is as a statement about what came before it: everything up to this point parsed cleanly under the rules the parser was following. When the reported position is the very end of the document, the problem is almost always an unclosed brace, bracket, or quote somewhere above. Formatting a partially-correct copy of the document is often the fastest way to find it, because indentation makes an unbalanced nesting level visible at a glance.
What JSON does not allow
Six things trip people up constantly, and they share a cause: all six are perfectly legal in a JavaScript object literal, so they slip in whenever someone copies code into a config file. Trailing commas after the last element. Single-quoted strings. Unquoted property names. Comments of either kind. The values NaN and Infinity. And leading zeros on numbers.
JSON has no comments by design - the format's author removed them specifically because people were using them to carry parsing directives. That omission is why so many tools that read JSON configuration actually read something else. JSON5 and JSONC both add comments and trailing commas back, and are what your editor is quietly accepting when it lets a comment sit in a tsconfig or a VS Code settings file.
This tool validates strict JSON, the format defined by RFC 8259, and rejects all six. That is deliberate: if you are about to send a document to an API or commit it as a data file, you want to know now that a strict parser will refuse it, not after deployment.
Formatting versus minifying
Indentation is for humans and for diffs. A formatted file produces a version-control diff that shows the one field you changed, rather than a single unreadable line marked as modified in full. That alone is reason enough to keep JSON in source control formatted.
Minifying is for the wire, and it matters less than it appears to. Whitespace compresses extremely well, so gzip or brotli already recovers most of the difference before the bytes leave the server. Minify at build time or at response time; storing minified JSON in a repository trades a real, daily cost in reviewability for a saving your transport layer was going to make anyway.
Frequently asked questions
- Is my data uploaded anywhere?
- No. Validation and formatting both run in your browser, and nothing is transmitted. Close the tab and the text is gone. There is no server-side copy to leak.
- My editor accepts this file, so why does it fail here with a trailing comma?
- Your editor is almost certainly parsing JSON5 or JSONC rather than strict JSON. Both allow trailing commas and comments, and both are common for configuration files. Strict JSON does not, and neither will the API you are about to send this to.
- How large a document can this handle?
- The limit is your browser's memory rather than any upload cap, so multi-megabyte files generally work. Formatting is synchronous though, so a very large document will freeze the tab for a moment while it runs. Validation is debounced as you type to keep that from happening on every keystroke.
- Does formatting reorder or change my data?
- Key order is preserved - formatting only changes whitespace. There is one exception worth knowing: if your document contains duplicate keys in the same object, only the last one survives, because that is how any JSON parser resolves them. The duplicate silently disappears from the output, so if a field goes missing after formatting, check for a repeat of that key higher up.