JSON Formatter

What this works out

JSON looks simple until a formatter changes data that was never supposed to be interpreted. The common shortcut is JSON.stringify(JSON.parse(file)). That produces tidy output, but it also passes every number through JavaScript’s binary64 Number, collapses duplicate object names to one value, and chooses new escape and exponent spellings.

This tool separates validation from rewriting. The browser’s JSON parser proves that the complete source is a conforming value. A second, deliberately smaller scanner copies the original tokens and changes only the whitespace RFC 8259 calls insignificant.

The method

RFC 8259 defines a JSON text as whitespace, one value, then whitespace. A value can be an object, array, number, string, true, false or null. The only whitespace characters in the grammar are space, tab, line feed and carriage return, and they are permitted around six structural characters:

[  ]  {  }  :  ,

That gives the formatter a narrow edit surface. Outside a quoted string those four whitespace characters can be removed. Inside a string, a space is data, and a backslash determines whether the next quotation mark ends the string or is part of it. The scanner therefore keeps two bits of state: inside a string and the previous character was an escape.

Readable mode inserts a newline and indentation after a non-empty {, [, or comma, a single space after a colon, and a newline before a non-empty closing container. Minified mode inserts nothing. Neither mode converts a primitive token into a language value.

Before you read on

Which formatter is safe for the JSON number 9007199254740993?

• AParse it as a JavaScript Number, then stringify it.

  That integer is one above Number.MAX_SAFE_INTEGER and can be rounded before it is written.

• BValidate the grammar, then copy the original number token.

  Yes. Validation and token-preserving output are separate jobs.

• CPut the number in quotes automatically.

  That changes its JSON type from number to string.

Validate the document, then carry the original number token into the output. RFC 8259 permits implementations to limit numeric precision and identifies the interoperable exact-integer range around 2^53; a whitespace formatter does not need to spend that precision at all.

A worked example

The one-line source is:

{"invoice":9007199254740993,"notes":"keep  two spaces","items":[true,null]}

With Readable and 2 spaces, the downloaded file is exactly:

{
  "invoice": 9007199254740993,
  "notes": "keep  two spaces",
  "items": [
    true,
    null
  ]
}

The two spaces inside "keep two spaces" remain data. The large invoice number keeps its original digits. The deepest nesting is 2: the root object is level 1 and its array is level 2. The formula test asserts the complete output bytes, filename, MIME, byte counts and depth shown by the result panel.

Why number text and object order remain untouched

RFC 8259 permits number magnitudes and precision beyond what binary64 can hold, while noting that integers from -(2^53)+1 through (2^53)-1 are the range implementations commonly agree on exactly. A formatter that parses 9007199254740993 into binary64 may write 9007199254740992. Removing a line break never required that conversion, so this tool does not do it.

The RFC also says object names should be unique, then documents what happens when they are not: some parsers keep the last value, some fail, and some expose all duplicates. It similarly notes that libraries differ over whether member order is visible. Sorting or deduplicating may be useful in a specialised data cleanup workflow, but neither is honest under a button labelled Format.

What it does not do

It does not repair invalid JSON, quote bare object names, remove comments, accept trailing commas, sort keys, or convert JSON5. Those operations need a policy for ambiguous input. Here malformed input is reported and the original file remains untouched.

It also does not change character encoding. Interoperable JSON is UTF-8, and an initial UTF-8 BOM is accepted only because RFC 8259 allows parsers to ignore one for compatibility. To recover known UTF-16 plain text, convert the bytes first; do not ask a JSON formatter to guess what characters they meant.