JSON formatter

JSON document
266 B minified · tree
Source
11 lines
1
2
3
4
5
6
7
8
9
10
11
Tree
Object(6)
order:"A-1183"
status:"shipped"
customer:Object(3)
name:"Ada Lovelace"
email:"ada@example.com"
vip:true
items:Array(2)
0:Object(3)
1:Object(3)
shipping:Object(3)
carrier:"DHL"
tracking:null
eta:"2026-09-02"
total:51
StatusValid
Nodes21
Depth4
Minified266 B

JSON Formatter

Paste JSON and read it as a collapsible tree or as formatted text, with the first syntax error located by line and column instead of a vague complaint. Sort keys to make two payloads comparable, minify for transport, and see what the document actually contains — depth, key count, and byte size.

Views: tree and text
2
Where an error is reported
line:col
Indent styles
3
Bytes uploaded
0

Step by step

How to use it

  1. 01Paste the document

    Parsing runs as you type, in your browser. An API response with customer data in it never leaves the machine.

  2. 02Read it as a tree, or as text

    The tree collapses objects and arrays so a large payload is navigable — open depth 2 by default. Text view gives the formatted document to copy, at two spaces, four spaces, or tabs.

  3. 03Sort keys when you need to compare

    Two responses that differ only in key order look completely different in a diff. Sorting both puts them in the same shape first, which turns a wall of changes into the two values that actually moved.

  4. 04Minify when it is going over the wire

    Minified output strips every space and newline. That is the form to paste into a config field, an environment variable, or a query string — not the form to read.

Worked example

Reading a parse error

The most common reason to open a JSON formatter is that something refused to parse. The error is reported as a position, and the position is usually one character after the real mistake.

Given

Symptom
Unexpected token }
Reported at
line 5, column 3
Actual cause
line 4

The classic trailing comma

{
  "name": "ada",
  "roles": ["admin", "editor"],
  "active": true,      <- the comma here has nothing after it
}                       <- the parser complains here
Error points at
the next token
Fix belongs on
the line before
Valid JSON allows
no trailing comma

A parser reports where it gave up, not where you went wrong — it reads the comma, expects another key, and finds a closing brace. Whenever the position looks innocent, check the line above it. Trailing commas and single quotes are the two mistakes that produce this pattern, and both are legal in JavaScript, which is why they are so easy to write.

Before you paste it somewhere

What to know about JSON

JSON is not JavaScript

No trailing commas, no comments, no single quotes, no unquoted keys, and no undefined. Everything on that list is valid in a JavaScript object literal, which is why documents copied out of source code so often fail to parse. The scanner here names which rule was broken rather than just refusing.

Errors point at the symptom, not the cause

The reported line and column is where the parser could no longer continue, which is typically the token after the mistake. Read the line above the one you are sent to — that is where the missing comma, the extra comma, or the unclosed string actually lives.

Key order is not meaningful, but diffs think it is

Objects are unordered by definition and two servers may serialise the same data differently. Sorting keys on both sides before comparing is what turns an unreadable diff into a two-line one — the same trick that makes JSON worth normalising before it goes into version control.

Formatting changes bytes, never meaning

Indentation, key order, and minification all produce different text for identical data. Judge a payload by what it parses to, not by how it looks — and minify only when the destination is a machine, since a minified document is essentially unreviewable.

Depth is what makes a payload hard to work with

The stats report nesting depth alongside key count and size, because depth is the number that predicts pain. Anything past four or five levels is usually a schema problem rather than a formatting one, and the tree view is the fastest way to see where it happened.

Nothing is uploaded

Parsing, formatting, and sorting all run locally. That matters for JSON specifically, because the documents people need to inspect are usually API responses full of real customer records, tokens, and internal identifiers.

The judgement call

Which output do you want?

The same document, four ways, depending on who reads it next.

  • Reading an unfamiliar API response

    Tree view

    Collapsed by default at depth 2, so the shape is visible before the contents drown you.

  • Pasting into code or a document

    2 spaces

    The convention almost everywhere. Four is fine internally; the point is consistency across your repo.

  • Comparing two responses

    Sort keys, both

    Removes ordering noise so the diff shows only values that changed. Do it to both sides, not one.

  • An env var, config field, or query string

    Minify

    One line, no whitespace. Anywhere a newline would break the container wants this form.

  • Committing a fixture to version control

    Format + sort

    Stable formatting and stable key order mean future diffs show real changes rather than serialisation drift.

  • The document has comments in it

    Not JSON

    That is JSONC or JSON5. Strip the comments, or use a parser built for the dialect — this one follows the spec.

Reference

What the spec actually allows

Trailing commas
InvalidLegal in JavaScript, rejected by JSON. The single most common parse failure.
Comments
InvalidNo // or /* */. Documents carrying them are JSONC or JSON5, not JSON.
Strings
Double quotes onlySingle quotes are invalid, and keys must be quoted — both are legal in a JavaScript object literal.
Numbers
No NaN, Infinity, or leading +Also no leading zeros. A value your language prints happily may not be serialisable.
Indent options
2 spaces · 4 spaces · tabFormatting only — the parsed value is identical whichever you choose.
Reported stats
Keys · depth · bytesDepth is the figure worth watching: it predicts how hard the payload will be to consume.

FAQ

Questions, answered plainly

How do I format JSON?

Paste it in. The document is parsed as you type and formatted immediately — pick two spaces, four spaces, or tabs, or switch to the tree view to explore it by collapsing branches. Everything runs in your browser; nothing is sent anywhere.

Why does my JSON say unexpected token?

Almost always a trailing comma, a single quote, an unquoted key, or an unclosed string. The parser reports where it stopped, which is usually the token after the mistake — so if the reported line looks fine, check the line above it.

Is a trailing comma allowed in JSON?

No. JavaScript object literals permit one and JSON does not, which is why documents copied out of source code so often fail. The same applies to comments, single-quoted strings, and unquoted keys — all valid JavaScript, none valid JSON.

How do I compare two JSON documents?

Format both with the same indent and turn on sort keys for each, then run them through the text diff checker. Without sorting, two payloads carrying identical data can differ on every line simply because the server serialised the keys in another order.

What is the difference between minified and formatted JSON?

Only whitespace. Minified JSON is one line with every optional space removed, which is what you want in a config value, an environment variable, or a query string. Formatted JSON is the same data laid out for a person to read. Both parse to exactly the same value.

Is my JSON uploaded anywhere?

No. Parsing, formatting, sorting, and minifying all happen in your browser, which matters because the documents people need to inspect are usually API responses containing real customer data, tokens, and internal identifiers.

Parsing, formatting, sorting, and minifying all run in your browser. No document is uploaded, logged, or retained — which matters when the JSON you are inspecting is a live API response.