Pretty-print, validate, or minify JSON. All in your browser.
Format, validate, and minify JSON in your browser. Paste raw JSON to get pretty-printed output with configurable indentation; paste pretty JSON to minify it for production. Validation errors are surfaced with line and column numbers so you can fix malformed JSON without guessing. Nothing leaves your browser.
JSON looks simple — it's just braces, brackets, colons, and commas — but the moment you start editing it by hand, the format becomes tedious. A misplaced comma in a 2,000-line API response means the whole file fails to parse. A trailing comma that's perfectly legal in JavaScript is a syntax error in JSON. A single unescaped quote in a string value silently corrupts everything after it. The JSON Formatter handles three jobs that come up constantly in development: turning ugly minified JSON into readable indented JSON, turning indented JSON into compact production-ready JSON, and finding exactly where your JSON is broken when it won't parse.
All three operations run instantly in the browser using the native JSON parser. The validator is the same one your runtime will use, so if it parses here, it parses everywhere — and if it fails here, the error message tells you exactly where to look.
Reading API responses. Most APIs return minified JSON to save bandwidth. Pasting the response into the formatter with 2-space indentation makes it actually readable — you can see the structure, find the field you're looking for, and copy a sub-tree without scrolling through one giant line.
Debugging webhook payloads. Webhooks from Stripe, GitHub, Slack, or any modern SaaS arrive as JSON. When the integration breaks, you need to see what was actually sent. Format the payload, eyeball the structure, find the field with the wrong type or unexpected null.
Preparing JSON for documentation. Code blocks in documentation read better with consistent indentation. The formatter normalizes whatever copy-paste produced into clean, predictable indented JSON ready to drop into Markdown.
Minifying for production. Build pipelines should minify JSON automatically, but sometimes you need to ship a config file by hand or paste a JSON blob into a script. Minify mode strips all unnecessary whitespace, producing the smallest valid representation.
Catching syntax errors before deployment. A broken package.json, tsconfig.json, or manifest.json doesn't always fail loudly — sometimes a tool just silently uses defaults. Validating before commit catches errors at the right moment.
Cleaning up exports. Database dumps, log exports, and CMS backups often produce JSON with inconsistent formatting. Re-format to normalize.
Comparing two responses. When you need to diff two API responses, format both with the same indentation first. Different whitespace produces noisy diffs that hide real changes.
Valid JSON is stricter than valid JavaScript object syntax. The differences cause a surprising number of bugs.
No trailing commas. {"a": 1, "b": 2,} is valid JavaScript. It's invalid JSON. The trailing comma after 2 must be removed.
Keys must be double-quoted strings. {a: 1} works in JavaScript. JSON requires {"a": 1}. Single quotes don't work either: {'a': 1} is invalid.
Strings must use double quotes. {"a": 'value'} is invalid; only {"a": "value"} works.
No comments. JSON has no syntax for comments. // like this or /* like this */ will both fail to parse. JSON-with-comments (JSONC) is a separate, non-standard format that some tools support; standard JSON does not.
No undefined or NaN. JSON's value types are limited to string, number, boolean, null, object, and array. undefined and NaN have no valid representation. null is the closest substitute.
Numbers can't have leading zeros. 007 is invalid; 7 works. Decimals must have a digit before the dot: .5 is invalid; 0.5 works.
Special characters in strings must be escaped. Backslash, quote, newline, tab, and the Unicode control characters all need escape sequences (\\, \", \n, \t, \u0000). A literal newline inside a string is invalid.
The formatter supports 2-space, 4-space, and tab indentation. Choosing between them is mostly about ecosystem convention.
Two-space indentation is the dominant convention in modern JavaScript and TypeScript projects. Most popular linters (Prettier, ESLint with default rules) format JSON files with 2 spaces. If you're editing JSON inside a JavaScript codebase, 2 spaces is the safe choice.
Four-space indentation is more common in Python projects and certain enterprise environments. It produces slightly more readable nested structures at the cost of more horizontal space. Some legacy projects still standardize on 4.
Tab indentation is rare in JSON. It works (the JSON spec allows any whitespace between tokens), but most tooling defaults to spaces, and you'll get inconsistent rendering across editors that interpret tab width differently. Avoid unless your project explicitly requires tabs.
Smart quotes from text editors. When you paste JSON into Word, Pages, Google Docs, or some chat applications, straight double quotes (") get auto-converted to curly "smart quotes" (", "). Smart quotes are not valid in JSON; the parser rejects them. If your JSON looks correct but won't parse, this is the most common cause. Re-paste from a plain-text source.
BOM at the start of files. JSON files saved from some Windows editors include a Byte Order Mark — an invisible character at byte 0. Most parsers tolerate it; some don't. If pasting from a file produces "Unexpected token" at position 0, the BOM is the cause.
JSONP confused with JSON. JSONP wraps JSON in a function call: callback({"a": 1});. This is not parseable as JSON — strip the wrapper before formatting. Look for an opening identifier and parenthesis at the start, and a closing parenthesis (and possibly semicolon) at the end.
Concatenated JSON ("JSON Lines"). Some log formats and streaming APIs produce one JSON object per line, separated by newlines but not wrapped in an outer array. This is valid JSON Lines (NDJSON) but invalid JSON. Wrap the lines in [...] with commas between them to convert.
Numbers losing precision. JSON numbers are double-precision floats. Integers larger than 2^53 (roughly 9 × 10^15) lose precision when parsed in JavaScript. If you need exact representation of very large integers (Twitter snowflake IDs, Discord IDs, blockchain values), encode them as strings instead.
This tool validates JSON syntax — does it parse? Format and minify only.
JSON Schema validates JSON content against a schema — are required fields present, are types correct, are values within allowed ranges? Use a JSON Schema validator (Ajv, JSON Schema Validator) when you need to check the shape of JSON, not just whether it parses.
JSONLint and similar online linters usually do exactly what this tool does: parse and pretty-print. The tradeoff is whether you trust the tool with your data — this tool runs entirely client-side, so your JSON never leaves your browser. Many online linters send JSON to a server.
Paste JSON into the input box. The tool calls JavaScript's native JSON.parse() to validate and parse, then JSON.stringify() with your selected indentation to format. If parsing fails, the error from the JavaScript engine is surfaced with line and column numbers calculated from the position in the input.
Minification calls JSON.stringify() with no indentation argument. The result is the most compact valid representation, with all unnecessary whitespace removed. Validation alone (no formatting change) is also available — useful when you want to confirm JSON is parseable without modifying it.
Performance scales with input size. JSON up to several megabytes formats and minifies in well under a second on modern browsers.
Always validate before committing config files. A broken package.json or tsconfig.json can cause your build to silently fall back to defaults, leading to mysterious bugs that take hours to track down. A 5-second validation pass before commit prevents this.
Minify before storing in a database column. If you're storing JSON in a TEXT or VARCHAR column, minified JSON saves a meaningful amount of space (often 20–40%) without losing any information.
Format before sharing. Pasting minified JSON into Slack or email forces the recipient to format it themselves. Format it first.
Use minify + format as a "round trip" sanity check. Format your JSON, then minify it, then format it again. If the final output matches the first formatted version, your JSON has no semantically meaningful whitespace problems.
JavaScript object literal syntax is more permissive than JSON. JavaScript allows unquoted keys, single quotes, trailing commas, and comments — none of which JSON allows. To convert a JS object to JSON, the safest path is JSON.stringify(obj) in a JavaScript console.
Not with this tool. JSON5 and HJSON are extensions that allow comments, trailing commas, unquoted keys, and other quality-of-life features. They require dedicated parsers. This tool handles standard JSON only.
Yes. JavaScript's JSON.stringify preserves insertion order for string keys, so your output keys appear in the same order as your input. (Object key ordering was undefined behavior in older specs but is guaranteed in ES2015+ for string keys.)
Browsers can handle nesting depths in the thousands without issue. Practical concern only at extreme depths (10,000+) where stack overflow becomes possible.
That's the native JavaScript engine's error format. Look at position N in the input — the actual error is often a few characters before what's reported (a missing comma or quote that the parser only noticed when it hit the next token).
The tool tolerates a leading BOM and strips it before parsing. Some other tools don't, so if you're producing JSON for downstream systems, save without BOM to be safe.