JSON Formatter
Paste a JSON blob — minified, escaped, or straight out of a log line — and get it pretty-printed with the indent size you choose. Validates on parse and shows the exact line and column of any error. Optionally sort object keys alphabetically, which makes diffs across two API responses much easier to read.
How to format JSON
-
1
Paste the JSON
Minified, escaped inside a string, or wrapped in a JSONP callback — the parser strips it all.
-
2
Pick indentation
2 spaces, 4 spaces, a tab, or compact (single-line for small payloads).
-
3
Toggle sort keys
Alphabetically sort object keys to make two responses easier to diff.
-
4
Copy or download
One-click copy to clipboard, or save as a `.json` file.
What the formatter handles
- Minified input:
{"a":1,"b":[1,2,3]}becomes properly indented. - Escaped JSON in strings: a JSON string that contains
"{\"nested\":true}"can be unwrapped and formatted. - JSONP callbacks:
callback({...})is stripped to just{...}. - BOM and leading whitespace: removed automatically.
- Comments: JSONC-style
//and/* */are tolerated in “lenient” mode but stripped from the output (strict JSON has no comments).
Why pretty-print JSON
- Diffing: a single-line JSON document with thousands of keys is unreadable in a
git diff. Pretty-printed, each key is a line. - Debugging: nested structures are easier to navigate visually with indentation.
- Documentation: API examples should always be formatted, sorted and stable across reissues.
- Configs: JSON config files should be pretty-printed in the repo for readability; runtime can parse either form.
Indentation conventions
| Context | Typical indent |
|---|---|
npm package.json |
2 spaces |
| AWS CloudFormation | 2 spaces |
| Legacy Java / .NET | 4 spaces |
| Configs in VCS | 2 spaces (project-wide consistency matters most) |
Sort keys is controversial: it makes diffs cleaner but changes the on-disk order of canonical configs. Pick a project convention and stick to it.
Validation errors you will see
| Error | Fix |
|---|---|
Unexpected token ' at position X |
You used single quotes; change to double quotes |
Unexpected end of JSON input |
Missing closing brace or bracket |
Unexpected token , at position X |
Trailing comma; remove it |
Unexpected token a at position X |
Unquoted key or NaN/undefined literal |
Duplicate key "foo" (lenient mode) |
JSON spec allows it; most parsers keep the last |
Common mistakes
- Copying JSON with HTML entities.
"will not parse; decode first. - Mixing strict and lenient. Use lenient parsing only for inspection; never save lenient JSON to production configs.
- Pretty-printing an already pretty-printed file in a different style. The formatter will happily do it, but you will create a noisy diff.
Frequently Asked Questions
No. Parsing and formatting both run in your browser. The content never leaves your tab — safe for pasting API responses with tokens, internal configs or staging payloads.
The formatter pretty-prints valid JSON. The validator checks against a JSON Schema. Both run a parse check, but validation is a separate step that asks “does this match my schema?” rather than just “is this valid JSON?”.
Yes. The “sort keys” option sorts all object keys at every nesting level, recursively. Arrays keep their original order because array order is semantically meaningful in JSON.
Limited by browser memory. Up to ~50 MB works on modern hardware. Beyond that, consider jq from the command line — it streams rather than loading the whole document.