The JSON you are staring at is usually valid in spirit and broken in detail. A hand-assembled config is missing a comma, a payload copied out of a terminal log arrived truncated, a snippet pasted from a document has smart quotes in it, and the failure surfaces three layers away as a parse error with a byte offset and no context. Formatting is the fastest way to see any of that, because an indented view puts the offending token on a line you can read. Past debugging, formatting is what makes a payload reviewable: nobody can review a diff of two minified 40 KB responses, but everybody can review a diff of the pretty-printed versions and see the one field that changed. There is a second reason to do this in a browser tab rather than on a website, and it is the reason this tool does not upload anything. API response bodies routinely carry access tokens, session identifiers, personal records and internal hostnames, and pasting those into a form that posts them to somebody else's server is a leak you chose to make on purpose. Here the parse and the re-serialisation happen inside the tab you already have open.
What the specification actually allows
JSON is defined by RFC 8259, and the rules that bite are all in the grammar. Object keys and string values must be double quotes; single quotes make the document invalid. There are no comments, no trailing commas, and no unquoted identifiers, which is the most common reason a JavaScript object pasted from the console fails to parse. There are exactly six value types: object, array, string, number, true, false and null, with no undefined, no NaN, no Infinity and no date literals. Numbers are strict too: no leading plus sign, no leading zeros, no hexadecimal, no trailing decimal point. Control characters inside strings have to be escaped, and a backslash must itself be escaped, which is why a Windows path such as C:\Users\me breaks the document unless every backslash is doubled. Duplicate names in one object are technically tolerated, though the specification says names should be unique and behaviour when they are not is unpredictable - most parsers silently keep the last one, which means a duplicated key is a data loss bug that no error message will ever report.
What pretty printing changes, and what it hides
Indentation is whitespace, and whitespace is not part of the data, so reformatting cannot change meaning on its own. The subtlety is what a formatter has to do to produce that indentation in the first place: it has to parse the text into a language value and print it back out. That round trip is not the identity function. A duplicate key collapses to one. Number formatting is normalised, so 1.0 prints as 1, 1e2 prints as 100, and anything past the safe integer range loses digits. Escape sequences get rewritten, so a unicode escape may come back as the literal character, which is the same value but a different byte sequence. If a wire format or a signature depends on the exact bytes, a pretty printed copy is not a drop-in replacement. And the pair of things people expect to survive - comments and trailing commas - are not valid JSON at all, so a formatter that accepted them would be describing a different format, which is what JSONC and JSON5 are for.
Precision and key order: the two traps a round trip hides
JavaScript numbers are double precision, which means integers up to roughly 9 quadrillion are exact and everything beyond that is rounded. JSON.parse does not warn you: an order identifier of 12345678901234567890 comes back as 12345678901234567000, silently, and if you send it back out again the damage is now in your database. Nanosecond timestamps, snowflake identifiers and money stored in minor units are the usual casualties. The fix is either to keep such values as strings in the document, or to parse with a lossless library that keeps big integers as BigInt or as a decimal object. The second trap is key order. JavaScript objects list integer-like keys first, in ascending numeric order, and only then string keys in insertion order, so an object written as 10, 9, 2 comes back as 2, 9, 10. That is why sorting keys is an opt-in here rather than the default: it produces stable output for diffing, and it destroys any order a human was relying on, including the priority fields some tools read top-down.
Sorting, minifying and diffing real payloads
Two transformations earn their keep in daily work. Sorting keys alphabetically makes two responses from different sources comparable, which is what turns a wall of text into a readable diff - paste the two versions side by side in a diff viewer and the single changed field is obvious. Minifying removes the whitespace, which matters when a payload is embedded in a URL, stored in a cache key, or posted from a device with a slow uplink. The habit worth forming is to diff the original against the formatted output once, before you start trusting either. If nothing but whitespace changed, the document was already canonical. If something else changed, you have just found a number precision problem or a duplicate key, and you want to know that now rather than in production.
Frequently asked questions
Is my JSON sent to a server?
No. The text is parsed and re-printed inside your browser tab, and nothing is transmitted; this page has no upload endpoint. The site is supported by advertising, so ad providers can see page-level details such as your IP address and which pages you visit, but not the contents of your editor.
Why does my JSON fail to parse when it looks correct?
The usual four: a trailing comma before a closing brace, single quotes or unquoted keys copied from JavaScript, smart quotes pasted from a word processor or a chat app, and an unescaped backslash in a Windows path. A fifth is worth adding to the list - an ellipsis where a log was truncated. The reported line and column usually point at the token after the real mistake, so look one line above it.
Does formatting change my data?
Indentation itself cannot, because whitespace is not data. But producing that indentation means parsing and re-printing, and that round trip normalises numbers, may collapse duplicate keys, and can rewrite escape sequences. If the exact bytes matter, for example because something signs or hashes the document, keep the original and treat any formatted copy as a debugging artefact.
How large a file can it handle?
It depends on the device, not on the tool. JSON parsing in the browser is synchronous, so a very large document will freeze the tab while it works, and a multi-megabyte response is usually fine on a desktop but unpleasant on a phone. If you are formatting a multi-gigabyte export, use a streaming command line tool instead.