JSON Formatter

Reading a Payload That Arrived as One Line

A payload comes back from an API as a single 4,000-character line, you need to know whether plan.dataGb is in there, and the terminal has wrapped the whole thing into a grey slab. Pretty-printing it is a two-second job that everybody solves twice a week, so the interesting question is not whether a formatter indents — every one of them does — but what it changes on the way through. This one is built so the answer is nothing except whitespace.

That matters more than it sounds, because the obvious implementation quietly corrupts data. Formatting normally means JSON.parse then JSON.stringify, and JavaScript numbers are IEEE-754 doubles that hold about 15 to 16 significant digits — so a 19-digit SIM identifier does not survive the trip. Paste {"iccid": 8901240544102066246} into a console, round-trip it, and what comes back is 8901240544102066000. No error, no warning; three digits are simply gone. This page reads long integers straight out of your source text and writes them back digit for digit, which is why the example further down keeps all nineteen.

Everything else is the ordinary job, done carefully: two-space indentation, one key per line, and a parse failure reported with a line and a column you can click rather than a flat "invalid". The rules being applied are the ones in RFC 8259 — no trailing commas, no comments, no single quotes — and if you want the grammar on one page, json.org still has the clearest diagrams anyone has drawn for it.

Formatting a Document, Step by Step

1. Paste or upload – Paste into the left panel, or use "Upload" to pick a .json file — an uploaded file is pretty-printed into the input pane, so you can edit it there rather than in your editor.
2. Read the right panel – Formatting runs about a third of a second after you stop typing, so it keeps up with a paste but does not fight you mid-keystroke. Two-space indentation, one key per line, original key order.
3. If it says Invalid JSON, use the position – The error panel carries the line and column the parser stopped at and a link that puts your caret exactly there. That is usually enough — the character that broke the document is almost always a few positions before the one it complained about.
4. Copy or download – "Copy" puts the formatted text on your clipboard; "Download" saves it as a .json file. Both read the output pane, so what you get is what you can see.
5. Minify to go back the other way – The "Minify" button collapses the formatted output back to one line, using the same precision-preserving serialiser — so a document can go format → minify → format and the digits still match.

Pro Tip: If the document is an array of similar records, formatting only makes it taller. Send it to JSON to Table instead and read it as rows and columns — indentation is the wrong tool for repetition.

Example

A subscriber record as it arrives from an HSS lookup: one line, 112 bytes, unreadable. On the right is exactly what this page returns for it — 9 lines, 144 bytes. Look at the iccid. It still ends in 246. A plain JSON.parse → JSON.stringify round trip writes 8901240544102066000 on that line instead, which is the failure this page is built to avoid.

{"msisdn":"447700900142","iccid":8901240544102066246,"plan":{"name":"Unlimited 5G","dataGb":100},"roaming":true}

{
  "msisdn": "447700900142",
  "iccid": 8901240544102066246,
  "plan": {
    "name": "Unlimited 5G",
    "dataGb": 100
  },
  "roaming": true
}

Common Use Cases

Debugging an API response

The endpoint returns minified JSON and you are looking for one field. Formatted, the answer is a glance: objects open and close where you expect, an unexpected null stands out on its own line, and a value that should be a number but arrived as "100" is visible because of the quotes. It is also where you notice the field you were promised is simply absent, which is the bug about half the time.

Validating Configuration Files

Working with JSON config files for your application? Before you deploy and risk breaking things, paste your config here. If there's a syntax error—a missing comma, an unclosed bracket—you'll spot it immediately in the formatted output. Once both your old and new configs are formatted the same way, a side-by-side text compare makes it trivial to see exactly which keys actually changed before you ship.

Checking what a system actually stored

Someone reports that an identifier came back wrong from an integration, and the first job is finding which hop broke it. Format the payload at each stage and compare the digits by eye — this page will not be the hop that lost them, which makes it a usable reference point. If the answer turns out to be a spreadsheet in the middle of the chain, that is a different and much older problem; MDN's note on how JavaScript encodes numbers explains why 15 digits is the boundary everywhere it shows up.

Frequently Asked Questions

Does my JSON leave the browser?

No. Parsing and formatting are done by code running in this tab, so a document you paste never crosses the network. You can confirm it the direct way: load the page, disconnect, and keep formatting. Nothing here is stored or logged either — reload and the pane is empty again.

Will formatting change any of my values?

Strings come back byte-identical, and integer literals are preserved exactly however long they are — 8901240544102066246 stays 8901240544102066246 rather than rounding to …066000, because integers are lifted out of your source text instead of being converted to JavaScript numbers. Three things do change, and it is better to know than to be surprised by them.

So what does change, exactly?

First, decimals and exponents are re-printed in shortest form: 1.50 becomes 1.5, 1.0 becomes 1, and 1e5 becomes 100000. The number is the same number — JSON has no notion of trailing zeros — but the text is not, so do not diff a formatted file against a hand-written one and expect silence. Second, duplicate keys collapse to the last one: {"a":1,"a":2} formats to a single "a": 2, with no warning, because that is what every JSON parser does. Third, keys that look like array indices are re-sorted ahead of the rest — {"20":…,"3":…,"tac":…} comes back with "3" first. That last one is a JavaScript object rule rather than anything to do with JSON, and it catches people once each.

What happens if my JSON has errors?

The output pane shows "Invalid JSON" with the parser's own description and, when the message carried one, the line and column. Missing comma, unclosed bracket, a trailing comma copied out of JavaScript, and smart quotes pasted from a document are the four you will actually hit. If the answer is not obvious from the position, Stack Overflow's JSON tag has the odd ones, and the JSON Fixer will attempt a repair on a document you did not write yourself.

How large a file can it handle?

There is no size limit in the code, and no chunking either — the whole document is parsed and re-serialised on every change, so cost scales with the file, not with what you are looking at. A few hundred kilobytes is comfortable. A file of several megabytes will make the tab pause on each edit, and at that point you are better off slicing the part you need out with jq and formatting that.

What's the difference between beautify and minify?

Direction only. Beautify adds the indentation and newlines; minify strips them back out. Neither touches a value, so the round trip is safe both ways — the JSON Minifier is the same serialiser with the indent argument left off.

Related Tools