JSON Formatter

Formatting JSON means adding the whitespace a human needs and a machine does not: one member per line, consistent indentation, a space after each colon. The data does not change. Only its presentation does.

The part that is easy to get wrong is that last sentence. A formatter that parses your document into JavaScript values and stringifies them back has already rewritten your numbers before it prints anything, and most of them do exactly that.

What formatting does not change

This formatter re-emits the tokens it read rather than re-serialising parsed values. That means the text of every number, string and literal comes back byte for byte, and only the whitespace between them is rewritten.

It matters more than it sounds. Run a document containing a 19-digit ID through a formatter built on JSON.parse and JSON.stringify and the ID comes back different, silently, with no warning anywhere in the interface.

Numbers keep their exact text

1.50 stays 1.50, 1e3 stays 1e3, -0 stays -0, and 12345678901234567890 stays itself rather than becoming 12345678901234567000.

Strings are copied verbatim

An escaped \u00e9 stays escaped and a literal é stays literal. Formatting is not the place to decide how a string should be encoded, so it does not.

Key order is preserved

Unless you explicitly turn on sorting. JSON objects are unordered by specification, but every parser in practice preserves insertion order and diffs depend on it.

Duplicate keys are kept and flagged

Removing one would change what a consumer sees. You get a warning naming both positions instead.

Which indentation to choose

Two spaces is the default here because it is what npm, Prettier and most JavaScript tooling emit, and because nesting in JSON gets deep quickly. Four spaces reads better for shallow configuration files. Tabs let each reader pick their own width, which is the accessibility argument for them, and they compress marginally better.

For anything transmitted rather than read, minify instead. Whitespace in a JSON response is pure overhead, and on a typical API payload it is between 10 and 20 per cent of the bytes.

Line endings and trailing newlines

The output uses LF by default. A CRLF option exists because Windows tooling and some CI systems care, and because a file that mixes both produces a diff where every line appears changed.

Whitespace outside strings is insignificant to a parser, so none of this affects validity. It affects your diffs, which in practice is what you notice.

How to do this in code

The same operation in code. All of these produce two-space indentation; every one of them will also rewrite your numbers, which is the trade you accept when the payload has no large integers in it.

const pretty = JSON.stringify(JSON.parse(text), null, 2);

// Tabs
const tabbed = JSON.stringify(JSON.parse(text), null, '\t');

import json

pretty = json.dumps(json.loads(text), indent=2)

# Keep non-ASCII readable rather than escaping it
pretty = json.dumps(json.loads(text), indent=2, ensure_ascii=False)

# From the command line
# python -m json.tool --indent 2 input.json

jq . input.json              # 2 spaces, the default
jq --indent 4 . input.json
jq --tab . input.json
jq -c . input.json           # compact

var buf bytes.Buffer
if err := json.Indent(&buf, data, "", "  "); err != nil {
    return err
}

// json.Indent works on raw bytes, so unlike Unmarshal it does
// not touch your numbers at all.

require 'json'

pretty = JSON.pretty_generate(JSON.parse(text))

$pretty = json_encode(
    json_decode($text),
    JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE
);

Questions

Is there a size limit?

No limit is imposed by this page. The practical ceiling is your browser: a JavaScript engine caps a single string at about 512 MB, so nothing larger can be held at all. Formatting a 10 MB document takes roughly 780 milliseconds of work here, which runs in a background worker so the page stays responsive.

Does formatting change my data?

No. Whitespace outside strings has no meaning in JSON, and this formatter re-emits every value exactly as you wrote it rather than parsing and re-serialising. Turning on key sorting does change the document, and it is off by default for that reason.

Why does my formatted file look different from what my editor produces?

Most likely a trailing newline or the array-of-objects style. Some formatters keep short arrays on one line; this one is consistent, which produces more lines but far more readable diffs.