JSON Formatter & Validator

What this JSON formatter does

JSON — JavaScript Object Notation — is the plain-text format that modern software uses to talk to itself: APIs return it, configuration files are written in it, apps store data in it. It is meant to be readable by humans as well as machines, but in practice it often arrives as one unbroken line of thousands of characters, or as a hand-edited file with a mistake hiding somewhere inside. This tool answers the two questions you actually have about a blob of JSON. First: is it valid? The Format button runs your text through a strict JSON parser — the same grammar browsers, servers and databases all enforce. If the parse succeeds, your JSON is valid, full stop. Second: can I read it? Valid JSON is reprinted with consistent indentation (your choice of two or four spaces) so the nesting structure stands out, objects and arrays open and close at predictable places, and a long payload becomes something you can scan, diff and debug. The Minify button runs the process in reverse, squeezing the same data into a single whitespace-free line for production use. Neither direction changes the data — only its clothing.

Because formatting requires a complete successful parse, formatting is validation. There is no separate "check" that can pass JSON this tool would fail to format, and no formatted output is ever produced from invalid input — a partial or best-guess result would be worse than useless, because you could paste it onward believing it was fixed.

When validation fails: reading the error

When the parser chokes, the tool reports the position of the failure as a line and column rather than dumping a raw error message at you. One subtlety is worth knowing: the parser reports where it gave up, which is at, or more often just after, the real mistake. If the error says line 4, column 19, look at the character there and then walk backwards a few characters — the culprit is usually the token right before. In practice almost every broken JSON file fails for one of these handful of reasons:

• Trailing commas. {"a": 1,} and [1, 2,] look harmless and JavaScript allows them, but JSON does not.
• Single quotes. JSON strings and keys require double quotes: {'a': 'b'} is invalid.
• Unquoted keys. Every property name must be a quoted string — {a: 1} is JavaScript object syntax, not JSON.
• Comments. JSON has no comment syntax at all; a // note left in a config file breaks it.
• Non-JSON values. undefined, NaN, functions and dates-as-objects cannot appear. Use null for "no value".
• Truncated copies. A payload cut off mid-paste leaves brackets unclosed, and the error position lands at the very end of the text.

Format or minify — which do you want?

Format anything a human will read, edit, review or debug: sample API responses while developing, configuration files, test fixtures, data you are about to paste into a bug report. The two-space indent is the common convention in web projects; four spaces reads a little easier on deeply nested data and matches many desktop tools. Minify when size is what matters: inline payloads, stored documents, anything transmitted so often that whitespace becomes real bandwidth. Minified JSON is also the fairest way to compare two documents for equality — if the minified forms match character for character, the data is identical. And a caution in the other direction: never hand-edit minified JSON. One missing comma in a 40,000-character line is a miserable hunt; format first, edit, then minify again if you must.

A quick example. This minified fragment — {"user":{"name":"Ada","roles":["admin","editor"]},"active":true} — formats into seven readable lines with the nested "user" object clearly indented under the top level. Try it above; it is a good first test of any formatter.

Private by design: this formatter runs entirely in your browser. JSON you paste here is never uploaded, stored or shared.