Prettify Compact JSON for Debugging

A REST endpoint returns a compact body. Prettify at 2-space to see the envelope structure at a glance during debugging.

Input (single line):
{"data":{"user":{"id":42,"name":"Ada"}},"meta":{"trace":"7f3a"},"errors":[]}

Output (2-space):
{
  "data": {
    "user": {
      "id": 42,
      "name": "Ada"
    }
  },
  "meta": {
    "trace": "7f3a"
  },
  "errors": []
}

The same endpoint serialized fields in different orders across two deploys. Sorting keys makes the two prettified outputs diff cleanly so the only highlighted line is the real change.

Capture A: {"name":"Ada","id":42,"role":"admin"}
Capture B: {"id":42,"role":"user","name":"Ada"}

Both prettified with Sort keys ON:
A:                      B:
{                       {
  "id": 42,               "id": 42,
  "name": "Ada",          "name": "Ada",
  "role": "admin"         "role": "user"   <- only real diff
}                       }

A copied response had a trailing comma left by a hand-edit. The tool refuses to format it and tells you exactly where — that is the bug, not the formatting.

Input:
{"a":1,"b":2,}

Result:
invalid JSON: Expected double-quoted property name in
JSON at position 13 (line 1 column 14)

Fix the trailing comma (or run json-format-fixer), then
re-prettify.

A Twitter/Snowflake-style 64-bit ID exceeds JavaScript's safe integer range. JSON.parse rounds it — this is a real data-corruption trap, not a formatting choice. Keep such IDs as strings at the source.

Input:
{"tweet_id":12345678901234567890}

Output:
{
  "tweet_id": 12345678901234567000
}

The last digits changed. If you need the exact ID,
the API must emit it as a string: "12345678901234567890".

Prettify to inspect a fixture, then minify it back to a single line to drop into an inline assertion.

Pretty (read in editor):
{
  "ok": true,
  "count": 3
}

Run json-minifier ->
{"ok":true,"count":3}

Paste back into the test. No data changed, only whitespace.

Strict JSON.parse rejects JSONC. You get invalid JSON: Expected ',' or '}' after property value (or a property-name error for the trailing comma). The prettifier does not strip these — run json-format-fixer first, which removes trailing commas, quotes unquoted keys, and converts single quotes, then prettify the repaired output.

NDJSON (one JSON object per line) is not a single JSON document, so JSON.parse throws Unexpected non-whitespace character after JSON. Prettify one line at a time, or for log-line formatting see the structured-log guide. This tool formats exactly one value per run.

JavaScript numbers are IEEE-754 doubles, so any integer above 9,007,199,254,740,991 is rounded on parse — 12345678901234567890 becomes 12345678901234567000. The output is valid JSON but the value changed. There is no BigInt mode; the only safe fix is for the producing API to emit large IDs as JSON strings.

{"a":1,"a":2} is technically allowed by the grammar but JSON.parse keeps only the last occurrence, so the output is {"a":2} and the first value is silently dropped. If you suspect a duplicate-key bug in a producer, this tool will hide it — inspect the raw bytes instead.

JavaScript objects place integer-like keys first, in ascending numeric order, before any string keys — regardless of the Sort keys toggle. {"b":1,"2":2,"1":3} re-emits as {"1":3,"2":2,"b":1}. Key order is therefore not always byte-preserved; if exact order matters, keep the data as an array.

Sorting uses localeCompare, so apple, Banana, cherry sort as apple, Banana, cherry — not the ASCII/code-point order (Banana, apple, cherry) that jq -S produces. This is fine for human reading but means the byte output can differ from a jq-sorted file; pick one tool consistently for diff stability.

JSON.parse then stringify canonicalizes numbers: 1e3 becomes 1000, 0.10 becomes 0.1, and 1.0 becomes 1. The mathematical value is identical, but the literal text changes — keep this in mind if you are byte-diffing prettified output against a hand-formatted original.

A bare 42, "hello", true, or null is a valid JSON document and prettifies fine (indent has no visible effect on a scalar). This is expected — JSON's top level need not be an object or array.

Free JSON tier caps a single file at 2 MB. Larger debug captures are blocked with an upgrade prompt; Pro raises the JSON file limit to 100 MB. Very large documents also hit the in-browser 5,000-character preview truncation — that is display only; Copy and Download still return the whole document.

After text.trim(), an empty string is not valid JSON, so you get invalid JSON: Unexpected end of JSON input. Confirm you actually saved the response body and not an empty placeholder.