Online JSON Formatter & Validator

A formatter does not insert line breaks into your text with a regular expression. It parses the document into an in-memory value - objects, arrays, strings, numbers, booleans and null - and then writes that value back out with an indentation setting. That round trip is why formatting is reliable: if the parse succeeds, the output is guaranteed to be valid JSON, because it was produced by a serializer rather than by string surgery.

It also explains the one surprise people hit. Because the text is rebuilt from parsed values rather than edited in place, anything that was not part of the data model disappears. Comments are gone. Original number spelling is gone. The gap between `{ "a":1 }` and `{"a" : 1}` is gone, because both parse to the same value. What survives is exactly the data, and nothing about how it happened to be typed.

Key order is preserved. JSON objects are unordered by specification, but every mainstream parser keeps insertion order, and this formatter does too - so a formatted file diffs cleanly against its source. If you want alphabetical order instead, that is a deliberate, separate operation.

Numbers are normalised to their shortest round-trip representation. `1.0` becomes `1`, `1e3` becomes `1000`, and `-0` becomes `0`. The numeric value is identical; only the spelling changes. This matters if you are diffing formatted output against a file that used a different numeric style, because those lines will show as changed even though nothing semantically moved.

Strings keep their characters but may change their escaping. A literal emoji stays an emoji rather than being converted to a `\u` escape sequence, and an existing `\u0041` escape is resolved to `A`. Both forms mean the same string; the formatter emits the readable one and escapes only what JSON requires - quotes, backslashes and control characters.

You cannot serialise a document you failed to parse, so every format attempt is implicitly a validation pass. When the parse fails, the underlying error carries a character offset into the source text. Converting that offset into a line and column is what turns an unhelpful "Unexpected token" into a cursor position you can jump to.

This is worth knowing because it sets expectations about error reporting. A JSON parser stops at the first problem - it does not collect a list of every error in the file. Fix the reported position, run it again, and the next problem surfaces. On a badly mangled document that can mean several passes, which is normal rather than a sign the tool is struggling.

Formatting is memory-bound rather than CPU-bound. A parsed JSON document typically occupies several times the size of its text form, because every string, array and object becomes a separate heap allocation. A 50 MB file can therefore need a few hundred megabytes of working memory once parsed, and the formatted output adds indentation on top of that.

In practice, multi-megabyte documents format comfortably in a modern desktop browser. Tabs on memory-constrained devices, and files in the hundreds of megabytes, are where you should expect trouble - and the honest answer there is a streaming command-line tool like `jq`, which never holds the whole document in memory at once.