JSON Beautifier

Turning Minified JSON Into Readable JSON

Real API responses almost never arrive in a readable state. Servers send the smallest payload they can, so what lands in your network tab is one enormous line with no breathing room. Here is a paginated search response exactly as it comes off the wire.

{"status":"ok","page":2,"total":147,"results":[{"id":9013,"title":"Coastal Survey","author":{"name":"R. Iyer","orcid":"0000-0002-1825-0097"},"year":2023,"open_access":true,"citations":[9011,8890]},{"id":9014,"title":"Tidal Drift Models","author":{"name":"L. Fournier","orcid":null},"year":2024,"open_access":false,"citations":[]}]}

Nothing about that is wrong, and a machine reads it perfectly well. A human cannot. You cannot tell how many results came back, which fields belong to the record and which belong to the nested author object, or whether the citations array is empty for one of them. Beautified, all of that is visible without reading a single character carefully.

{
  "status": "ok",
  "page": 2,
  "total": 147,
  "results": [
    {
      "id": 9013,
      "title": "Coastal Survey",
      "author": {
        "name": "R. Iyer",
        "orcid": "0000-0002-1825-0097"
      },
      "year": 2023,
      "open_access": true,
      "citations": [9011, 8890]
    },
    {
      "id": 9014,
      "title": "Tidal Drift Models",
      "author": {
        "name": "L. Fournier",
        "orcid": null
      },
      "year": 2024,
      "open_access": false,
      "citations": []
    }
  ]
}

The shape is now obvious at a glance: a wrapper with three metadata fields and a results array holding two records, each with a nested author object and a citations array. The second record has a null orcid and no citations, which was effectively invisible in the compact version.

What Beautifying Does and Does Not Change

Beautifying touches whitespace between tokens and nothing else. Values are not altered, types are not converted, keys are not reordered, and the meaning of the document is identical before and after. Any program consuming the beautified version receives exactly the same data structure it would have received from the compact one.

There is one exception worth understanding, and it catches people out. Because beautifying is a parse and re-serialize round trip, numbers are rewritten from their parsed numeric value rather than copied as text. The value is unchanged mathematically, but its written form may not survive.

input   ->  {"a": 1.0, "b": 1e3, "c": 0.10, "d": 5E-2}
output  ->  {"a": 1,   "b": 1000, "c": 0.1, "d": 0.05}

Every one of those pairs is numerically equal, so no data was lost. But if something downstream compares the raw text, or if a signature was computed over the exact bytes, the round trip will break it. Never beautify a payload whose signature you still need to verify, and be careful with fixed-point values such as currency that you may have been relying on trailing zeros to display.

Reading Deeply Nested JSON

Beautified output stops helping somewhere around six or seven levels of nesting. At that depth the indent alone consumes a third of the line, the key you care about is far from the left margin, and the closing braces at the bottom form a staircase that tells you nothing. A few practical adjustments help.

• Drop to two-space indentation for deep documents. Four spaces at depth eight puts your data 32 columns in before it starts.
• Collapse arrays of records first. A list of 200 similar objects adds thousands of lines and almost no information once you have read the first entry.
• Switch to a tree view when you are exploring rather than editing. A collapsible tree lets you keep one branch open and everything else shut, which flat text cannot do.
• Extract the sub-object you actually need into a separate buffer and beautify that on its own. A 40-line fragment is far easier to reason about than a 4,000-line document.

Escape Sequences in Beautified Output

The single most common surprise after beautifying is that strings containing newlines still look like one long line. This is correct behaviour, not a formatting failure. Indentation lives between tokens, and a string is a single token. Whatever is inside the quotes is data, so the formatter must leave it exactly as it found it.

{
  "message": "Line one\nLine two\tindented",
  "quote": "She said \"maybe\" and left",
  "path": "C:\\Users\\dev\\config.json",
  "symbol": "\u00e9 is e with an acute accent"
}

Reading that back: the backslash n stays written as two characters because turning it into a real line break would change the string from one token into two lines of broken syntax. The escaped quotes must stay escaped or the string would terminate early. The doubled backslashes in the Windows path are one literal backslash each. And the six-character unicode escape is one character in the parsed value, which some formatters will render directly and others will leave in escaped form. Both are valid JSON and both parse to the identical string.

If you need to see the real newlines, parse the JSON and print the string value on its own. Beautifying the document will never do it for you, and any tool that claims to is producing invalid JSON.

When you are done reading, the JSON Viewer gives you a collapsible tree and the JSON Minifier compresses the result back down for shipping. Browse the full collection of free JSON tools to find the right one for the job.