paste your json and instantly format, validate, or minify it. see errors with line numbers.
formatted output will appear here
“JSON formatter” is the umbrella name; in practice you usually want one of four different things, and the formatter on this page does all of them.
All four happen locally in your browser using the native JSON.parse / JSON.stringify pair. Nothing is sent to a server.
The JSON spec is famously short — the formal grammar fits on a T-shirt. That brevity hides a few corners that catch people regularly.
JavaScript object and array literals tolerate a trailing comma: { "a": 1, } is valid JS. JSON does not, and JSON.parserejects it. About a third of “why is my JSON broken?” cases come down to a stray trailing comma copied from a JS source file.
JSON has no comments. Not //, not /* */. If your config file uses them, it is technically JSON5 or JSONC, not JSON, and the standard parser will reject it. (Several sibling formats — JSON5, JSONC, HJSON — were created specifically to add the missing ergonomics; none of them are interchangeable with JSON proper.)
JSON numbers are a single decimal grammar. They are not typed. That sounds liberating until you realize that JSON.parse always returns a JavaScript Number, which is a 64-bit float. An ID of 9007199254740993 (1 above Number.MAX_SAFE_INTEGER) will round silently. If you are processing IDs from databases that emit them as numbers, this is a real footgun. A safer pattern is to emit IDs as strings.
JSON cannot represent NaN, Infinity, or -Infinity. Some tools emit those anyway. If a parser rejects your input with a complaint about an unexpected token N or I, this is usually why.
The JSON spec is silent on what to do when an object has two keys with the same name. Most parsers (including JavaScript's) take the last one and silently drop the rest. If you suspect a duplicate-key problem, JSON.parse alone will not warn you.
Browser JSON.parse throws a SyntaxError with a message like Unexpected token } in JSON at position 142. The byte position is what we have to work with. The formatter walks the input forward to that byte, counts newlines along the way, and renders a line/column pointer in the editor.
This is more useful than “your JSON is invalid” without a location, but it does have one quirk: the error position is the spot where the parser noticed something was wrong, not necessarily where the actual mistake is. A missing closing brace at the top of a file usually surfaces as an error near the bottom, when the parser ran out of input expecting more.
Tip
The formatter defaults to two-space indentation, which has won the de facto standard for JSON in the last decade. That said, the choice does not matter to a parser — it is purely cosmetic. If your team writes config files with four-space indentation, switch the setting and paste; the output will match.
For minified output, no indentation at all is the goal. The minifier removes every whitespace character that does not change semantics, including the spaces inside object key/value separators. The result is the smallest valid representation of the same data.
Plenty of JSON formatters live on web servers. There is no good reason for that. JSON.parse ships in every browser at native speed, the data does not benefit from any cloud-side processing, and uploading your potentially sensitive config file (with API keys, internal endpoints, customer data) to a third-party server is the kind of unforced error this site exists to avoid.
For other developer odd-jobs that benefit from the same approach, see the related tools below — and the blog post on choosing between UUID, ULID, and nanoid for when you need to generate identifiers that are likely to end up inside a JSON document.
“JSON formatter” is the umbrella name; in practice you usually want one of four different things, and the formatter on this page does all of them.
All four happen locally in your browser using the native JSON.parse / JSON.stringify pair. Nothing is sent to a server.
The JSON spec is famously short — the formal grammar fits on a T-shirt. That brevity hides a few corners that catch people regularly.
JavaScript object and array literals tolerate a trailing comma: { "a": 1, } is valid JS. JSON does not, and JSON.parserejects it. About a third of “why is my JSON broken?” cases come down to a stray trailing comma copied from a JS source file.
JSON has no comments. Not //, not /* */. If your config file uses them, it is technically JSON5 or JSONC, not JSON, and the standard parser will reject it. (Several sibling formats — JSON5, JSONC, HJSON — were created specifically to add the missing ergonomics; none of them are interchangeable with JSON proper.)
JSON numbers are a single decimal grammar. They are not typed. That sounds liberating until you realize that JSON.parse always returns a JavaScript Number, which is a 64-bit float. An ID of 9007199254740993 (1 above Number.MAX_SAFE_INTEGER) will round silently. If you are processing IDs from databases that emit them as numbers, this is a real footgun. A safer pattern is to emit IDs as strings.
JSON cannot represent NaN, Infinity, or -Infinity. Some tools emit those anyway. If a parser rejects your input with a complaint about an unexpected token N or I, this is usually why.
The JSON spec is silent on what to do when an object has two keys with the same name. Most parsers (including JavaScript's) take the last one and silently drop the rest. If you suspect a duplicate-key problem, JSON.parse alone will not warn you.
Browser JSON.parse throws a SyntaxError with a message like Unexpected token } in JSON at position 142. The byte position is what we have to work with. The formatter walks the input forward to that byte, counts newlines along the way, and renders a line/column pointer in the editor.
This is more useful than “your JSON is invalid” without a location, but it does have one quirk: the error position is the spot where the parser noticed something was wrong, not necessarily where the actual mistake is. A missing closing brace at the top of a file usually surfaces as an error near the bottom, when the parser ran out of input expecting more.
Tip
The formatter defaults to two-space indentation, which has won the de facto standard for JSON in the last decade. That said, the choice does not matter to a parser — it is purely cosmetic. If your team writes config files with four-space indentation, switch the setting and paste; the output will match.
For minified output, no indentation at all is the goal. The minifier removes every whitespace character that does not change semantics, including the spaces inside object key/value separators. The result is the smallest valid representation of the same data.
Plenty of JSON formatters live on web servers. There is no good reason for that. JSON.parse ships in every browser at native speed, the data does not benefit from any cloud-side processing, and uploading your potentially sensitive config file (with API keys, internal endpoints, customer data) to a third-party server is the kind of unforced error this site exists to avoid.
For other developer odd-jobs that benefit from the same approach, see the related tools below — and the blog post on choosing between UUID, ULID, and nanoid for when you need to generate identifiers that are likely to end up inside a JSON document.
PDF utilities, image tools, developer helpers — all free, no signup.
Generate favicons at every size from any image.
Encode text or files to Base64, or decode Base64 back to text and files.
Convert SVG files to high-resolution PNG at any scale.
Generate MD5, SHA-1, SHA-256, and SHA-512 hashes for text or files.
Add text or logo watermarks to photos with custom position, opacity, and tiling.
Live regex tester and debugger.