Skip to main content

JSON Formatter

Turn minified JSON into something you can read.

Paste a single-line API response and get properly indented, readable JSON back. Jsonviewpro validates the input first, so if something is wrong you get the line, the column and a plain-English explanation instead of a cryptic parser message.

Array order is always preserved — only whitespace, and optionally key order, change.

Input JSON

Size: 0 BLines: 0

Formatted JSON

Paste valid JSON to see the output.
Size: 0 BLines: 0

What formatting actually changes

Formatting — also called pretty-printing or beautifying — parses the document into memory and writes it out again with line breaks and indentation, so its structure becomes visible. Whitespace between tokens carries no meaning in JSON, which is why a formatted document and a minified one parse to exactly the same value.

Before — one line, 137 bytes
{"order":{"id":"ord_48821","status":"shipped","items":[{"sku":"KB-MECH-87","qty":1},{"sku":"MS-ERG-02","qty":2}],"total":12858.46}}
After — 2-space indentation
{
  "order": {
    "id": "ord_48821",
    "status": "shipped",
    "items": [
      { "sku": "KB-MECH-87", "qty": 1 },
      { "sku": "MS-ERG-02", "qty": 2 }
    ],
    "total": 12858.46
  }
}

Same keys, same values, same array order. The only difference is that a person can now find the line they care about.

How to format JSON here

  1. Paste your JSON into the editor, drop a .json file onto it, or press Upload. Nothing is sent anywhere — the parse happens in this tab.
  2. Choose an indentation width, and optionally turn on Sort keys.
  3. Press Format, or use Cmd/Ctrl + Enter.
  4. Copy the result, or download it as a .json file.

If the document does not parse, nothing is reformatted. You get the line, the column and a plain-English reason instead — see the validator for the full list of causes.

Choosing an indentation width

WidthBest forWatch out for
2 spacesAlmost everything. It is what npm, jq, Prettier and most editors emit, so it matches whatever your repository already contains.Nothing — pick this unless you have a reason not to.
4 spacesShallow configuration files that people read closely.Deeply nested API responses push far to the right and start wrapping.
8 spacesRare. Occasionally used to match legacy house styles.Almost always too wide to read comfortably.
TabsAccessibility: tab width is a reader preference, so people who need larger indentation can set it themselves.Uncommon in JSON, and some tooling normalises it back to spaces.

What formatting does not preserve

This is the part most formatters never mention, and it matters. Formatting is a parse followed by a re-serialization, so anything the JSON number and string grammar treats as equivalent comes back in its canonical form — not the form you typed.

You wroteYou get backWhy
90071992547409939007199254740992Data loss. JavaScript numbers are IEEE 754 doubles, so integers above 2^53 − 1 cannot be represented exactly.
1.01A trailing zero carries no numeric meaning.
1e31000Exponent notation is normalised.
0.10000000000000000550.1The nearest double round-trips to the shorter form.
-00Negative zero is serialized without the sign.
"\u0041""A"Escapes are decoded, then re-encoded only where required.
{"a":1,"a":2}{"a":2}Duplicate keys are permitted by the spec but undefined in behaviour. The last one wins here.

Object key order *is* preserved unless you ask for sorting, and array order is never touched.

Sorting keys, and when not to

Sorting object keys alphabetically produces a canonical form: two documents containing the same data serialize to identical text. That makes them comparable by eye, by diff, or by checksum.

Sort keys on
{
  "active": true,
  "email": "john@example.com",
  "id": 1001,
  "name": "John Doe"
}

It is the wrong default for anything hand-edited. Configuration files usually put the important settings first on purpose, and alphabetising them destroys that ordering for no gain. Turn it on when you are normalising machine output; leave it off otherwise.

Array items are never reordered. Object key order carries no meaning in JSON; array order carries all of it.

Formatting large documents

Formatting is memory-bound rather than CPU-bound: the parsed object graph is typically several times larger than the text that produced it. A 50 MB file can occupy a few hundred megabytes once parsed, which is what actually limits a browser tab.

Jsonviewpro parses and re-serializes in a Web Worker, so the interface stays responsive while it works, and it warns before opening a file large enough to strain the tab. If you are routinely formatting files that big, do it from the command line instead — the section below shows how.

Formatting outside the browser

Command line
# jq — the standard tool, formats by default
jq . input.json > output.json

# jq with 4 spaces, and with keys sorted
jq --indent 4 -S . input.json

# Python, no extra install
python3 -m json.tool --indent 2 input.json output.json

# Prettier, for a whole repository
npx prettier --write "**/*.json"

All of them parse and re-serialize, so all of them are subject to the same caveats above — jq is the exception on large integers, because it keeps higher precision than a JavaScript engine does.

For a repository, put formatting in a pre-commit hook or in CI so it happens identically for everyone. The point is not the formatting itself; it is that nobody has to think about it again.

Why a document will not format

A formatter can only re-serialize something it can parse, so every formatting failure is a syntax error. In practice it is almost always one of these:

The usual suspects
{ "roles": ["admin", "user",] }   ← trailing comma
{ 'name': 'John' }                ← single quotes
{ name: "John" }                  ← unquoted key
{ "a": 1 } // note                ← comments are not JSON
{ "ok": True, "n": NaN }          ← Python / JS literals
{ "a": 1 "b": 2 }                 ← missing comma

Jsonviewpro names the specific problem, points at the line and column, and — where the fix is unambiguous — offers a one-click repair that shows you exactly what it changed. Your input is never modified without you asking.

Frequently asked questions

Does formatting change my data?
Almost never, but not quite never. Keys, values, types and array order are preserved. Numbers are rewritten in canonical form, so 1.0 becomes 1 and 1e3 becomes 1000, and integers larger than 2^53 − 1 lose precision — see “What formatting does not preserve” above.
Will it break my 64-bit IDs?
Yes, if they are sent as JSON numbers. 9007199254740993 comes back as 9007199254740992. Every JavaScript-based formatter has this limitation. The durable fix is to have the API send large identifiers as strings.
Can I format invalid JSON?
Not directly — a document has to parse before it can be re-serialized. Jsonviewpro explains what is wrong with a line and column, and can suggest a deterministic repair for unambiguous problems such as trailing commas or single quotes, which you review before applying.
Is there a keyboard shortcut?
Cmd/Ctrl + Enter, or Cmd/Ctrl + Shift + F. Cmd/Ctrl + Shift + M minifies.
Does the formatter preserve key order?
Yes, unless you turn on Sort keys. JSON objects have no defined ordering, but preserving the input order keeps diffs small.
What is the largest file I can format?
There is no fixed limit — it depends on your device’s available memory, because the parsed object graph is several times larger than the source text. Multi-megabyte files are comfortable. Jsonviewpro warns before opening a file large enough to strain the tab.
Is my JSON uploaded to format it?
No. Parsing and re-serializing happen in your browser. No request carrying your document is made — there is no server-side processing in this application to send it to.