Text & dev
JSON Formatter & Validator
Paste raw or messy JSON and clean it up in one click: Format rewrites it with tidy two-space indentation, Minify strips every needless space and line break for the smallest possible payload, and Validate checks whether the text is well-formed JSON. When something is wrong — a trailing comma, a missing quote, a stray bracket — you get a plain-English error message and, where the browser provides it, the exact position so you can jump straight to the problem. The tool uses your browser's native JSON engine, the same parser your code runs, so the result matches what your application will actually accept. Nothing is uploaded: your JSON never leaves the page, which makes it safe for API responses, config files and other data you would rather not paste into a random website.
Your JSON
Your formatted or minified JSON will appear here.
Formatting uses 2-space indentation. Validation and parsing use the browser's native JSON.parse.
How the JSON formatter works
Every action runs your text through JSON.parse, the same parser built into your browser and Node.js. If parsing succeeds, the tool has a real JavaScript value in memory. Format then calls JSON.stringify(value, null, 2) to print it back with two-space indentation and one key per line. Minify calls JSON.stringify(value) with no spacing, producing the most compact valid form. Validate parses and reports success without rewriting anything.
What each button does
Format → JSON.parse(text) then JSON.stringify(value, null, 2) Minify → JSON.parse(text) then JSON.stringify(value) Validate → JSON.parse(text) → valid or a positioned errorIf JSON.parse throws, the tool shows the browser's error message and, when available, the character index where parsing failed.
Notes & assumptions
- Standard JSON only: comments, trailing commas and single quotes are invalid and will be flagged.
- Object key order is preserved exactly as parsed by your browser.
- Very large documents are limited only by your device's memory, since everything runs locally.
Worked example: fixing a config file that will not parse
Your Node app crashes on startup while reading config.json, a 40-line file someone edited by hand. Paste the file above and click Validate. The status line reports something like: Invalid JSON, Expected double-quoted property name in JSON at position 812 (line 31, column 5). Jump to line 31 in your editor and the culprit is sitting right there: a comma after the last property of an object, left behind when a teammate deleted the line below it. Remove the comma, paste the corrected file, and Validate now confirms a valid object and shows its key count. Finish with Format so the whole file goes back to consistent two-space indentation before you commit it. The round trip takes under a minute, and because this page runs the same JSON.parse your application uses, a green result here means your app will accept the file too.
Common JSON errors and how to fix them
Six mistakes cause the vast majority of failed validations. The messages below are what Chrome and Node.js (the V8 engine) produce; Firefox and Safari word them differently but point at the same spot.
| Mistake | Example | Typical parser message | Fix |
|---|---|---|---|
| Trailing comma | {"a": 1,} | Expected double-quoted property name | Delete the comma after the last item |
| Single quotes | {'a': 1} | Expected property name or '}' | Use double quotes for keys and strings |
| Unquoted key | {a: 1} | Expected property name or '}' | Wrap the key in double quotes |
| Comment | {"a": 1} // note | Unexpected non-whitespace character after JSON | Remove // and /* */ comments |
| NaN or undefined | {"a": NaN} | Unexpected token 'N' … is not valid JSON | Use null or a quoted string instead |
| Byte-order mark (BOM) | file saved as "UTF-8 with BOM" | Unexpected token at position 0 | Re-save the file as UTF-8 without BOM |
The reported position is where the parser gave up, which is usually at or just after the actual mistake, so scan a few characters back if nothing looks wrong at the exact spot.
JSON is stricter than JavaScript
An object literal that is perfectly legal in a .js file is frequently invalid JSON, which is why pasting code into a validator can fail even though the same text runs fine in a console. JavaScript accepts unquoted keys, single-quoted strings, trailing commas, comments, NaN, Infinity, undefined and hex numbers such as 0xFF. JSON.parse rejects every one of those. JSON permits exactly six value types (object, array, string, number, true or false, and null), requires double quotes around every key and string, and has no expression syntax at all.
Numbers carry one extra trap: JavaScript stores every JSON number as a 64-bit float, which is exact only up to 9,007,199,254,740,991 (2^53 minus 1). Parse 9007199254740993 and you get back 9007199254740992. APIs that ship 64-bit ids, such as database or social-media ids, send them as strings for exactly this reason.
Minify or pretty-print?
Pretty-print anything a human reads: files committed to a repo, code-review diffs, API responses you are debugging. Minify anything a machine transmits or stores where bytes count. The gap is real: a sample array of 100 small three-field objects is 6,386 characters formatted with two-space indentation and 3,985 characters minified, a 38% reduction. One caveat: if your server gzips responses, and most do, compression squeezes repeated whitespace so effectively that minifying first saves far less over the wire than the raw character counts suggest.
Frequently asked questions
Why does my JSON say "Unexpected token" or fail to validate?
The most common causes are a trailing comma after the last item in an object or array, using single quotes instead of double quotes around keys and strings, unquoted keys, or a missing closing brace or bracket. Comments (// or /* */) are also not allowed in standard JSON. The error message and position shown by the validator point you to where the parser gave up, which is usually at or just after the real mistake.
What is the difference between Format and Minify?
Format (beautify) adds two-space indentation and line breaks so the structure is easy to read and review in a code editor or pull request. Minify removes all of that whitespace to produce the smallest valid JSON, which is what you want for API payloads, query strings or anything where byte size matters. Both produce exactly the same data — only the spacing differs.
Does this tool change my data or reorder keys?
No. The formatter parses your JSON into a value and prints it back, so numbers, strings, booleans, nulls, arrays and objects are preserved. Object keys keep the order your browser parsed them in, which for typical JSON is the order you wrote them. Only the indentation and whitespace are changed; the meaning of the document stays identical.
Is my JSON sent to a server?
No. The formatter, minifier and validator all run entirely in your browser with JavaScript. Your JSON is never uploaded, stored or logged, so it is safe to paste API responses, configuration files, tokens or other sensitive data. Close the tab and nothing is retained anywhere.
Can I format very large JSON files here?
Yes, within reason. Because all processing happens on your device, the practical limit is your computer's available memory rather than any server cap. Documents up to several megabytes format quickly on a modern machine. Extremely large files may briefly freeze the tab while the browser parses them, but no data is lost.
Can JSON contain comments?
Not in the standard. JSON deliberately has no comment syntax, so // and /* */ both make a document invalid, and this validator flags them exactly as JSON.parse would. If you control the format, common workarounds are a dedicated "_comment" key, or a superset such as JSONC (used by VS Code settings files) or JSON5, parsed with tooling that understands it. Strip the comments before feeding the text to a strict parser.
Why did a long number change after formatting?
JavaScript stores every JSON number as a 64-bit floating-point value, which represents integers exactly only up to 9,007,199,254,740,991. Anything longer is silently rounded during parsing: 9007199254740993 comes back as 9007199254740992. This is a property of the parser itself, not a bug in the formatter, and it is why APIs send 64-bit ids as strings. If an exact long id matters, keep it quoted.