Yoryantra
← Back to Tools

JSON Formatter

Pretty-print valid JSON while preserving source tokens that JavaScript re-serialization can silently change.

The input is validated first. Formatting then works on the original JSON token text rather than serializing the parsed JavaScript value back to JSON.

Formatting itself runs in the browser and makes no request containing the pasted JSON. Site-wide analytics or advertising scripts, browser extensions, and anything copied to the system clipboard sit outside that local processing boundary. Very large payloads are processed on the page and can briefly make the tab less responsive.

Pretty printing should not change the JSON you are inspecting

A common pretty-printing shortcut is JSON.stringify(JSON.parse(input), null, 2). That works for ordinary data, but it also means the browser has already turned every number into a JavaScript Number and every object into a normal JavaScript object before the text is recreated.

The input first passes JSON.parse() for syntax validation. Pretty printing is then applied to the original token text. That keeps exact number spellings, duplicate member text, escape spelling, and source key order visible instead of rebuilding the value from a JavaScript object.

Whitespace Outside a String and Whitespace Inside a String Are Completely Different

{"message":"Sneha  Pune","items":[1,2,3]}

becomes

{
  "message": "Sneha  Pune",
  "items": [
    1,
    2,
    3
  ]
}

Spaces between structural tokens can be replaced with indentation. The two spaces inside "Sneha  Pune" are string data and must remain untouched. Escaped characters inside strings are preserved for the same reason.

Large IDs Are a Good Reason Not to Re-serialize During Formatting

JSON itself allows number tokens with more integer precision or magnitude than JavaScript's Number type can represent exactly. An API may send a database identifier such as 9007199254740993. A JavaScript parse can no longer represent that exact integer as a Number, even though the source token is still sitting correctly in the response body.

Formatting the token text means the output can still show the exact numeric token the server sent. The warning tells you that application code using ordinary Number values may not see the same exact value.

Duplicate object names do not behave consistently across parsers

A JSON object such as {"role":"user","role":"admin"} contains the same member name twice. RFC 8259 says object names should be unique because behavior with duplicates is unpredictable across implementations. Some parsers keep the last value, some expose all duplicates, and others reject them.

Keeping both tokens visible makes the problem easier to diagnose. The warning does not make the duplicate safe to send to every consumer.

Key Order Can Be Preserved for Humans Without Becoming Application Logic

Developers often arrange object members in an intentional visual order—identity fields first, then configuration, then nested data. Preserving that source order makes code review and debugging easier. It should not be used to make business decisions, because JSON objects are modeled as unordered collections of name/value pairs.

Formatting Is Not JSON Schema Validation

Successful formatting means the text passed JSON syntax parsing. It does not prove that an API request contains the required fields, that an ID has the expected format, or that a payload satisfies a JSON Schema. Use the JSON Validator or JSON Schema Validator when the question is data correctness rather than readability.

RFC 8259 defines the JSON grammar, permits only space, tab, line feed, and carriage return as insignificant whitespace, explains why duplicate object names hurt interoperability, and discusses numeric interoperability limits. Read RFC 8259