Pretty Print JSON Online

Pretty printing JSON inserts whitespace at the positions surrounding structural characters, which are the opening and closing brackets and braces, colons between keys and values, and commas between items. RFC 8259 defines those positions as whitespace-tolerant, meaning a conforming parser must ignore any spaces, tabs, carriage returns, and newlines that appear there. The string content inside a quoted JSON string is not touched by pretty printing because the contents of a string token are semantically meaningful: a newline character inside a string is part of that string value and would change the parsed result if altered. The pretty printer therefore preserves every byte of every string value while adding visual structure around the tokens.

A common source of confusion is that pretty printing does not normalise the data in any other way. Key ordering inside an object is preserved as-is by JSON.stringify in modern JavaScript engines, with the exception that integer-like keys (keys that look like array indices) are emitted in numeric order first per the V8 enumeration rules. Numeric values keep their original representation only if they survive a round trip through JavaScript number precision: 1.0 becomes 1, 1e10 becomes 10000000000, and any value beyond the safe integer range may lose precision. If your JSON contains identifiers stored as numbers larger than 2^53, the pretty printer may silently truncate them. Store such values as strings in the source to avoid this entire category of bug.

Pretty printing is also not the same as canonicalising. Canonical JSON, as defined in drafts such as RFC 8785 JCS, mandates a specific key order, a specific number serialisation, and a specific escaping rule, so two structurally equivalent documents always produce byte-identical output. Standard pretty printing makes no such guarantees. If your workflow needs canonical output for signing, hashing, or content-addressable storage, run the pretty printed result through a JCS-conformant tool afterwards. For everyday human-readable inspection, the relaxed approach used by JSON.stringify is appropriate and matches what every developer expects from a browser-based formatter.

The pretty printer in FixTools handles a few practical edge cases that the bare JSON.stringify call does not. Inputs prefixed with a UTF-8 byte order mark are accepted because the tool strips the BOM before calling JSON.parse, whereas a raw JSON.parse call would reject any non-whitespace character at position zero. Inputs that contain a trailing newline or trailing whitespace after the document terminator are accepted because the tool trims surrounding whitespace first. Inputs that contain a single JSON document wrapped in additional whitespace inside a larger text block are not parsed automatically; extract the JSON region first and paste only that. These behaviours match what experienced developers expect from a forgiving formatter without silently changing the data.

Performance for typical inputs is bounded by rendering rather than parsing. JSON.parse in V8 runs at roughly 200 to 500 megabytes per second, and JSON.stringify with an indent argument runs at similar speeds because it walks the same parsed tree. The slow part of pretty printing in a browser is producing the syntax-highlighted DOM: every key, value, and structural character becomes a styled span, which can multiply the node count of the displayed text by an order of magnitude compared to plain text. For documents under 5 megabytes this is imperceptible. For documents in the 10 to 50 megabyte range expect a brief pause. For documents over 100 megabytes prefer a streaming command-line tool such as jq, which produces pretty printed output with constant memory regardless of file size.