Formatting Is Also Validation
A JSON formatter has to parse before it can indent, which means it fails on invalid input rather than producing prettier invalid input. That makes it a validator by construction: if the output appears, the document parsed, and if it did not, the error says where.
This tool formats at two or four spaces, minifies back down, and reports parse errors as you work.
How to Format JSON
Paste and pick an indent. Everything runs locally as you type.
- Paste your JSON into the editor.
- Choose two-space or four-space indentation. Two is the more common convention in JavaScript projects; four suits deeply nested configuration read on a wide screen.
- Use minify to strip every optional space and newline, which is what you want for anything sent over a network.
- Watch the validity indicator. It reflects whether the document currently parses.
- Read the error message if parsing fails, it points at the position where the parser gave up.
- Copy the result when it looks right.
The Errors You Will Actually Hit
Most invalid JSON fails for one of a handful of reasons, and nearly all of them come from writing JavaScript by habit. Trailing commas after the last element are legal in modern JavaScript and illegal in JSON. Keys must be double-quoted strings, so `{name: "x"}` fails where `{"name": "x"}` parses. Single quotes are not string delimiters. Comments do not exist in JSON at all, despite how often configuration files want them.
A few more are subtler. `NaN`, `Infinity` and `undefined` are not JSON values, so a serialiser that emits them produces something no parser will accept. Numbers cannot have leading zeros or a trailing decimal point. And a lone trailing brace mismatch is usually reported far from where the mistake actually is, since the parser only notices when it runs out of input.
Valid JSON Against Habitual JavaScript
The differences that account for most parse failures.
| Written as | Valid JSON? | Why |
|---|---|---|
| {"a": 1,} | No | Trailing comma |
| {a: 1} | No | Unquoted key |
| {'a': 1} | No | Single quotes |
| {"a": 1} // note | No | Comments are not part of JSON |
| {"a": NaN} | No | NaN is not a JSON value |
| {"a": .5} | No | Number needs a leading digit |
| {"a": 1} | Yes | Double-quoted key, valid number |
Every "No" in this table is valid JavaScript. That overlap is exactly why JSON errors are so common, the syntax is familiar enough that the differences do not announce themselves.
Formatting, Minifying and Precision
Formatting and minifying are lossless with respect to the data: whitespace outside strings carries no meaning in JSON, so both directions preserve the document exactly. Key order is preserved by this tool, though the specification does not require any parser to do so, and code that depends on object key order is relying on something JSON never promised.
One real caveat concerns numbers. JSON numbers are parsed into JavaScript doubles, so integers beyond 2^53 lose precision on the round trip, a common problem with 64-bit database identifiers, which is why APIs often send them as strings. Everything here runs in your browser and nothing you paste is transmitted or stored, which makes it safe for documents containing keys or personal data.
One thing a formatter cannot tell you is whether the document means what you intended. A file can parse perfectly and still have a misspelled key, a string where a number belongs, or a nested object at the wrong depth. Where the shape matters, a schema, JSON Schema being the common choice, validates structure in a way that parsing alone never will.