Minified JSON is one long line because whitespace between tokens carries no meaning in JSON. To read it, run it back through a parser and print it again with indentation — paste the line into the JSON formatter, keep the two-space indent, and it comes back as a tree. The whitespace itself is never the risk: adding or removing it cannot change a single value. The round trip through the parser is where things change, and one of those changes quietly loses data.
Why it arrived as one line
RFC 8259 names exactly four characters as insignificant whitespace between tokens: space, tab, line feed and carriage return. Insignificant means a parser skips them without looking. Minifying a JSON document is nothing more than deleting every one of them that sits outside a string — whitespace inside a string is data and stays exactly where it is.
The reason anyone bothers is that indentation is a real share of a pretty-printed file. At two spaces per level, a line nested four deep carries eight leading spaces plus a newline: nine bytes of nothing. A 5,000-line file whose lines average that depth is hauling around 45 kB of layout before a single character of data.
Over the network it matters less than that arithmetic suggests. Anything serving JSON sensibly sends it with gzip or brotli, and long runs of identical spaces are the easiest pattern a compressor will ever meet. Minifying still wins, just by a smaller margin than the byte count implies.
How to format it
Four places, depending on where the text already is.
- In the browser. Paste and pick an indent. Fastest route when the JSON came out of a network tab or a chat message and is not in a file yet. It also has a ceiling: the formatter here parses on the page's main thread, so a few megabytes is comfortable and a database export will lock the tab up for seconds or run out of memory.
- In your editor. Save the text with a
.jsonextension and run Format Document from the command palette in VS Code, or the equivalent in whatever you use. The advantage is that the editor keeps the file and lets you collapse sections afterwards. - On the command line.
python -m json.toolreads standard input and prints it indented with no extra install.jq .does the same with two-space indentation and syntax colour, andjq -c .goes back the other way when you need the compact form again. - Without formatting at all. Chrome's Network panel has a Preview tab that renders a JSON response as a collapsible tree, and Firefox ships a JSON viewer that does the same for any response served as
application/json. For a quick look at one response this beats copying anything anywhere.
What the round trip changes
A formatter does not sprinkle line breaks through your text. It parses the document into a value and prints that value again from scratch. Anything that was not part of the data does not come out the other side.
- Numbers are normalised.
1.0comes back as1and1e3as1000. The value survives; the way it was written does not. - Escapes are rewritten to the shortest legal form.
\u0041comes back asAand\u002Fas/, while\u0009comes back as\t. Control characters stay escaped either way, since JSON forbids them raw inside a string. - Duplicate keys collapse. The specification says names SHOULD be unique and leaves the rest undefined. JavaScript and Python both keep the last one, so a config with
"timeout"twice loses one of them on the way through, usually without a word. - Keys that look like numbers move.
{"2":"b","1":"a"}reprints with"1"first. That is a JavaScript object rule rather than a JSON one, and it is the one reordering you cannot switch off. - Comments do not exist. JSON has none, so a file containing them was never JSON and will not parse at all.
The one that actually loses data
Large integers. The JSON specification puts no limit on the size or precision of a number, but JavaScript holds every number as a 64-bit float, so integers above 9,007,199,254,740,991 cannot all be represented exactly. Hand a JavaScript parser 9007199254740993 and you get 9007199254740992 back with no error anywhere.
This lands on identifiers first: database IDs, Discord snowflakes, timestamps in nanoseconds. It is why well-built APIs send large IDs as strings. The formatter on this site scans for integer literals that change when JavaScript reads them and tells you which ones, but it cannot repair them — by the time the value exists, the digits are already gone. If you see that warning, treat the formatted output as unsafe to paste back into anything that matters.
Why the error says line 1, column 4812
This is the specific way minified JSON makes your day worse. Everything is on one line, so the parser reports a column number in the thousands and you have nowhere to look. You cannot format the file to find the problem, because the problem is why it will not format.
Two ways out. Paste the line into an editor and use its go-to-position box — the one in VS Code accepts line:column, so typing 1:4812 drops the cursor on the character in question. Or skip that and work down the list of things that are usually wrong, because the list is short:
- A trailing comma before a
}or a]. - Single-quoted strings or unquoted keys. Valid JavaScript, invalid JSON.
- A truncated response, which shows up as an unexpected end of input at the very last column.
NaNorInfinityfrom a serialiser that should have known better. Neither is legal JSON.- It is not JSON at all — an HTML error page copied out of the network tab, which fails on the very first
<.
Whatever the position says, remember it is where the parser gave up, not where you went wrong. A missing comma gets reported at the start of the following key, and an unclosed string gets reported at whatever quote comes next. Look just before the number you were given.
Some files are near misses rather than broken. JSON5 and JSONC allow comments and trailing commas and will fail in any strict formatter, including ours. NDJSON — one object per line with no wrapping array — fails too, because the second line is unexpected input; wrap the lines in an array yourself first. If what you actually wanted was a configuration format that lets you write comments, the trade between YAML and JSON is the honest version of that question.
Reading it once it is indented
Indentation on its own does not make a 4,000-line object comprehensible. Two things help before you start scrolling.
The first is shape. Nesting depth and key count tell you which problem you have: a payload five levels deep with forty keys reads very differently from one two levels deep with four thousand. The formatter prints the depth and the key count above the output, which is the cheapest way to find out which one you have before you start scrolling.
The second is sorting. Sorting keys alphabetically makes an unfamiliar object searchable, and it is safe by definition, since object members are unordered. It is also destructive in a way that matters for files people maintain: the author's grouping usually carried meaning. Sort a response you are inspecting, not a config file you are about to commit.
Sorting earns its keep when you are comparing two payloads. Format both with keys sorted, then run them through a line-by-line diff — without sorting, you get a diff full of lines that merely moved, and the one field that actually changed is buried in it.
And if the JSON turns out to be a flat array of objects — a list of rows with the same keys — indentation is the wrong view entirely. Three hundred records are unreadable as a tree and obvious as a table, which is what converting JSON to CSV is for, along with the fields that get lost when you do it.
Where minified JSON keeps turning up
API responses are the obvious source, but not the only one. Anything written to localStorage or a data- attribute went through JSON.stringify, which adds no whitespace unless you ask for it. Structured log lines are minified so one event stays on one line. And the middle segment of a JWT is base64url-encoded minified JSON, which is why decoding a token hands you a wall of text: you get the JSON back, still on one line, and still have to indent it.
All of these are right to stay minified where they live. The point is not to tidy the source — it is to get a readable copy in front of you for the two minutes you need it, then throw it away.
The JSON formatter here does the whole loop in one place: it indents or minifies, points at the line and column when the input will not parse, and warns you about the duplicate keys and oversized integers that parse cleanly and still cost you an afternoon. It runs in your tab, so the payload you are debugging is not uploaded anywhere.
If the text you are trying to read came out of a token rather than an API, what is actually inside a JWT covers the decoding step that comes first — and, more usefully, why reading the claims proves nothing about whether they are true.
Frequently asked questions
How do I format minified JSON?
Run it through a parser that prints the value back with indentation. A browser-based formatter, VS Code’s Format Document command, or the command-line tools "python -m json.tool" and "jq ." all do it. Whitespace between tokens is meaningless in JSON, so the indentation itself changes nothing — though the round trip through the parser can normalise numbers and drop duplicate keys.
Is there any difference between minified and pretty-printed JSON?
Not to a parser. Space, tab, line feed and carriage return between tokens are insignificant, so both forms describe the same value. The only differences are file size and whether a human can read it.
Why does my JSON error say line 1 with a huge column number?
Because the whole document is on one line, so the parser can only report how many characters in it stopped. Paste the text into an editor and use its go-to-position box, which in VS Code accepts a line:column pair. Also look slightly before the reported position, since a parser only fails once it reaches something that cannot come next.
Does formatting JSON change the data?
The whitespace itself does not, but the round trip through the parser can. Numbers are normalised so 1.0 becomes 1, escapes like \u0041 become the characters they stand for, and duplicate keys collapse to the last one. Above 9,007,199,254,740,991 integers can no longer all be held exactly, so some come back rounded in any JavaScript-based tool.
Can I format JSON that has comments in it?
No, because a file with comments is not JSON. Comments make it JSONC or JSON5, and a strict parser rejects them along with trailing commas and single-quoted strings. Strip the comments first, or use a tool built for the format your config loader actually expects.
Is it safe to paste JSON into an online formatter?
It depends entirely on whether the page uploads your text. Many formatters send it to a server, which is a problem when the payload contains customer data or an access token. Tools that parse in the browser never transmit anything, so the content stays on your machine.
Last updated September 19, 2026