Pasting a minified API response and getting back something a human can scan. Catching syntax errors — trailing commas, unquoted keys, smart quotes — with the exact line/column the parser tripped on. Stripping whitespace before pasting JSON into a context where size matters (URL params, env vars, config files). Confirming your hand-written JSON is valid before piping it into another tool.

JSON ≠ JavaScript object literal. Keys must be in double quotes. Single quotes, unquoted keys, and trailing commas all fail. If you've got JS object literals, run them through a converter first. Smart quotes from copy-paste. Word processors and chat apps love to "helpfully" replace " with " / " . Those aren't valid JSON delimiters. JSON has no comments. If your "JSON" has // or /* */ , it's actually JSONC (used by VS Code config) — strip those before parsing. Numbers larger than 2⁵³. JavaScript can't represent integers above 9007199254740992 exactly. Twitter snowflake IDs and similar should be quoted as strings.

Integer precision is the silent JSON bug. JavaScript's JSON.parse converts every number to a 64-bit float. Numbers larger than 2 53 −1 (9,007,199,254,740,991) lose precision silently — common with database IDs, Snowflake IDs, and timestamp-in-nanoseconds values. If your wire protocol uses 64-bit integers, transport them as strings. There's no warning when this fails; you just get the wrong number back. "JSON" often isn't JSON. Three dialects look identical but fail strict validation: JSONC (JSON with comments — VS Code config files, tsconfig.json), JSON5 (relaxed syntax with trailing commas, single quotes, unquoted keys, comments — common in tooling configs), and NDJSON / JSONL (one JSON object per line with no surrounding array — common in log pipelines and streaming exports). If your input fails to parse and looks mostly-valid, check which dialect you actually have. Indentation isn't aesthetic. 2-space and 4-space produce noticeably different file sizes. A 50KB pretty-printed JSON becomes roughly 80KB at 4-space and 30KB minified — meaningful when you're transporting config or caching responses. Rule of thumb: minify for HTTP, indent for human review and version control, never both formats in the same canonical store. Unicode "escape" is two different things. JSON spec allows escape sequences like é but also raw UTF-8 bytes. Both parse correctly; both display as "é". When diffing JSON files, inconsistent escape style produces noisy diffs even though the content is identical. Either run through a canonical formatter on every commit (this tool, used with the same indent setting), or accept the noise. Browser native usually wins on speed. Libraries like big-json and json5 exist for specific use cases (streaming huge files, parsing JSON5), but for routine parse/stringify on reasonable input sizes, the V8/SpiderMonkey native implementations beat any JS library by an order of magnitude. This tool uses native by design.

JSON Formatter

Format, validate, and minify JSON instantly. Errors highlighted with line and column.

Input

Output

Enter input above to see the result.

What is this for?

JSON travels minified — every byte counts when an API response is being shipped. But minified JSON is unreadable. This tool round-trips through the browser's native JSON.parse / JSON.stringify to produce indented, copy-able output, validate the structure, or strip whitespace back out. Nothing is uploaded; everything happens in the page.

When to use it

Pasting a minified API response and getting back something a human can scan.
Catching syntax errors — trailing commas, unquoted keys, smart quotes — with the exact line/column the parser tripped on.
Stripping whitespace before pasting JSON into a context where size matters (URL params, env vars, config files).
Confirming your hand-written JSON is valid before piping it into another tool.

Common gotchas

JSON ≠ JavaScript object literal. Keys must be in double quotes. Single quotes, unquoted keys, and trailing commas all fail. If you've got JS object literals, run them through a converter first.
Smart quotes from copy-paste. Word processors and chat apps love to "helpfully" replace " with " / ". Those aren't valid JSON delimiters.
JSON has no comments. If your "JSON" has // or /* */, it's actually JSONC (used by VS Code config) — strip those before parsing.
Numbers larger than 2⁵³. JavaScript can't represent integers above 9007199254740992 exactly. Twitter snowflake IDs and similar should be quoted as strings.

Expert notes

Integer precision is the silent JSON bug. JavaScript's JSON.parse converts every number to a 64-bit float. Numbers larger than 2⁵³−1 (9,007,199,254,740,991) lose precision silently — common with database IDs, Snowflake IDs, and timestamp-in-nanoseconds values. If your wire protocol uses 64-bit integers, transport them as strings. There's no warning when this fails; you just get the wrong number back.
"JSON" often isn't JSON. Three dialects look identical but fail strict validation: JSONC (JSON with comments — VS Code config files, tsconfig.json), JSON5 (relaxed syntax with trailing commas, single quotes, unquoted keys, comments — common in tooling configs), and NDJSON / JSONL (one JSON object per line with no surrounding array — common in log pipelines and streaming exports). If your input fails to parse and looks mostly-valid, check which dialect you actually have.
Indentation isn't aesthetic. 2-space and 4-space produce noticeably different file sizes. A 50KB pretty-printed JSON becomes roughly 80KB at 4-space and 30KB minified — meaningful when you're transporting config or caching responses. Rule of thumb: minify for HTTP, indent for human review and version control, never both formats in the same canonical store.
Unicode "escape" is two different things. JSON spec allows escape sequences like é but also raw UTF-8 bytes. Both parse correctly; both display as "é". When diffing JSON files, inconsistent escape style produces noisy diffs even though the content is identical. Either run through a canonical formatter on every commit (this tool, used with the same indent setting), or accept the noise.
Browser native usually wins on speed. Libraries like big-json and json5 exist for specific use cases (streaming huge files, parsing JSON5), but for routine parse/stringify on reasonable input sizes, the V8/SpiderMonkey native implementations beat any JS library by an order of magnitude. This tool uses native by design.