Format, validate and minify JSON, JSON with comments and JSON5, without changing a single value: every number is written back as the document spelled it. Errors carry a line, a column and the offending line. JSONPath queries, tree view, schema checks and diff
Initializing in your browser…
Format and validate XML without changing the document: CDATA, xml:space="preserve" and mixed content all survive, with errors carrying a line, a caret and a next step, plus XPath queries, a tree view and JSON conversion that names what JSON cannot carry
Format YAML without rewriting it: comments, anchors, quoting, block scalars, multi-document streams and the exact spelling of every number all survive, with YAML 1.1 and 1.2 both offered because the same file means different things under each
Generate a JSON Schema from a document and see whether it actually validates that document, with every number written back exactly as the file spelled it and formats checked against the calendar and the clock rather than by pattern
An API returned a single minified line of JSON holding an order identifier and a price, and you need to read it before filing a bug.
Minified
{"orderId":12345678901234567890,"price":19.90,"active":true}Formatted, with nothing changed
{
"orderId": 12345678901234567890,
"price": 19.90,
"active": true
}
line 1:12 12345678901234567890 is written back exactly as it is.
Read as a double it would be 12345678901234567000,
which is a different document.Most formatters run JSON.parse then JSON.stringify, which turns every number into a 64-bit float: that identifier comes back 12345678901234567000 and the price comes back 19.9. RFC 8259 section 6 sets no limit on the digits in a JSON number, so neither loss is required by the spec. This tool reads the document into a tree carrying the source text of every value and writes that text back, then tells you which numbers a float-based reader would round. Errors carry a line, a column and the offending line with a caret under it, and comments in JSONC and JSON5 are found with a lexer, so a URL inside a string survives.
JSON is strict about syntax in ways that surprise people. The spec (RFC 8259) requires double-quoted keys (single quotes are invalid), forbids trailing commas, forbids comments entirely, and requires all strings to be UTF-8. JavaScript object literals violate most of these rules and that is the most common source of confusion: code like `{foo: 1, "bar": 2,}` is valid JavaScript and invalid JSON. This formatter validates against the JSON spec, pretty-prints the result with configurable indentation, and reports the exact line and column of any error, with the offending line and a caret under the character, so you can find the problem without counting. The rule it holds to is that FORMATTING A DOCUMENT CHANGES ONLY ITS WHITESPACE. That sounds obvious and the usual implementation breaks it immediately: `JSON.stringify(JSON.parse(text))` turns every number into a 64-bit float and writes back whatever the float prints as, so the order identifier 12345678901234567890 comes out 12345678901234567000, the price 19.90 comes out 19.9, negative zero comes out 0, and 1e400 comes out null. RFC 8259 section 6 sets no limit on the digits in a JSON number, so none of that is required by the spec; it is an artefact of going through a float. This tool never turns the token into a number at all. It reads the document into a tree that carries the source text of every value and writes that text back, and it tells you which numbers a program using doubles would round, so you know before it bites you. Everything happens in your browser, which matters because JSON frequently contains credentials, API keys, or customer data you would rather not paste into a random online service. The collapsible tree view is built from the same tree, so it also shows the digits the file held rather than a rounded copy.
Indentation choice has subtle practical consequences. 2-space indent is the default in most JavaScript and web tooling, it keeps nested structures readable without consuming horizontal space, which matters when JSON gets embedded in code or documentation with margin constraints. 4-space indent matches Python's convention and is easier to scan at deep nesting levels because each level is visually distinct at a glance. Tab indentation is rare in JSON but occasionally required by legacy tooling. All four choices are here (2, 3, 4 spaces and a real tab character), alongside a minification mode that strips all whitespace for size-sensitive transport.
Comments and trailing commas cannot be removed with a search and replace, and that is worth stating because most tools try. A regular expression cannot tell a `//` that starts a comment from one inside a string, so a document holding `{"url": "https://example.com/a"}` gets cut at the first slash and stops parsing, and one holding `{"a": "/* keep this */"}` has its value emptied and still parses, which is worse. This tool reads with a lexer instead. Choose the dialect at the top: JSON is RFC 8259 exactly; JSON with comments adds // and block comments and a trailing comma in either container, which is what tsconfig.json and VS Code settings use; JSON5 adds unquoted names, single quotes, hexadecimal and leading-point numbers, a leading plus, Infinity and NaN, and line continuations inside strings. Writing a JSON5 document back out as JSON has to change some tokens, and every one of those changes is listed with its path and the reason, rather than happening silently.
Two members of one object can share a name. RFC 8259 section 4 says names SHOULD be unique and stops short of forbidding a repeat, and every mainstream parser quietly keeps the last one, so `{"price": 19.90, "price": 24.90}` becomes a single price and nothing tells you which. Here the repeat is reported with its line, both members survive by default, and if you do want one of them there is a setting saying which and a list of what it removed. The same care goes to member order: a JavaScript object silently reorders integer-like names ahead of everything else in ascending order, so `{"2":…,"10":…,"1":…}` comes back as 1, 2, 10 from any tool built on one. This tool keeps the order the file had unless you ask for a sort, and when you do it says which collation it used, because sorting by code point and sorting by your language are different orders.
It is worth knowing what JSON genuinely does not support. There is no Date type (ISO 8601 strings are the convention), no comments (teams invent hacks like `"_comment"` fields, or use JSONC), no multiline strings (you need literal \n escapes), and no undefined (null is the only nothing-value). What JSON does NOT lack is large numbers: section 6 sets no digit limit and only recommends the binary64 range for interoperability. Whether 12345678901234567890 survives depends entirely on what reads it, which is why this tool leaves it alone and warns you instead.
Format minified API responses into readable JSON to inspect data structures, spot missing fields, or verify correct values.
Reformat messy configuration files with consistent indentation before committing to version control.
Catch syntax errors, missing brackets, extra commas, unquoted keys, before they cause runtime failures in your application.
Collapse and expand nested objects to understand the shape of large JSON documents from third-party APIs or databases.
Format example payloads cleanly for API docs, README files, or technical specifications.
It identifies and reports syntax errors with their location, and where there is one obvious fix it names it: a Python True becomes true, a single quote is JSON5, a comma before a closing brace can be removed or the dialect switched. It does not apply the fix for you, because a missing comma could mean "add a comma" or "remove the key after it" and the tool cannot know your intent.
Because it went through JSON.parse and JSON.stringify. That turns every number into a 64-bit float and writes back what the float prints as, so 12345678901234567890 becomes 12345678901234567000, 19.90 becomes 19.9, -0 becomes 0 and 1e400 becomes null. RFC 8259 section 6 places no limit on the digits in a JSON number; the loss comes from the float, not from the spec. This tool writes every number back as the document spelled it and tells you which ones a float-based reader would round.
A 144 KB document of 5,000 objects formats in about two and a half seconds through the page, and 808 KB of 20,000 objects takes about 50 milliseconds in the parser itself. Everything runs in your browser, so a very large file is limited by the tab rather than by an upload.
Yes, as an explicit choice rather than a guess. Pick the dialect at the top of the tool. JSON with comments adds // and block comments and a trailing comma in either container, which is what tsconfig.json uses. JSON5 adds unquoted names, single quotes, hexadecimal and leading-point numbers, a leading plus, Infinity and NaN, and line continuations. Both are read with a lexer, so two slashes inside a string stay inside the string. Writing either back out as JSON lists every token that had to change.
They are reported with their line, and by default both survive. RFC 8259 section 4 says names SHOULD be unique and does not forbid a repeat, and every mainstream parser keeps the last and drops the rest with no message, which is how a duplicated field becomes a silent data loss. If you want the usual behaviour there is a setting for it, and it lists what it removed.
No. All formatting and validation happens entirely in your browser. Nothing is transmitted or stored.
Your text is processed locally in the browser. Nothing you paste or open is transmitted or logged.