JSON formatter

What this JSON formatter does

JSON (JavaScript Object Notation) is the most common format for moving structured data between programs — API responses, configuration files, log lines and more. It is designed to be compact, which also makes it hard to read once objects nest a few levels deep or arrive on a single line. This tool takes any JSON you paste and rewrites it two ways: beautified, with consistent indentation so the structure is obvious at a glance, or minified, stripped of every optional space so it is as small as possible to send over the wire.

It also validates as it formats. Because it parses the text before re-serialising it, invalid JSON never produces misleading output — instead you get the line and column where parsing failed, wherever it can work one out, so you can jump straight to the problem.

Beautify vs. minify — when to use each

The two modes serve opposite goals, and most workflows use both at different stages:

• Beautify when you are reading or debugging — inspecting an API response, comparing two payloads, or reviewing a config file in a pull request. Indentation turns a wall of text into a browsable tree.
• Minify when you are shipping — embedding JSON in HTML, storing it in a cookie or cache, or sending it in a request body where every byte counts. Minified JSON is byte-for-byte equivalent data, just without the whitespace.

The indentation selector (2 spaces, 4 spaces or a tab) only affects beautified output. Two spaces is the most common convention in JavaScript and web tooling; four spaces or tabs suit teams that prefer them. Whichever you pick, the result is still valid JSON — indentation is purely cosmetic.

Reading validation errors

When JSON is invalid, the tool reports the line and column of the first problem rather than a bare "invalid", except in the one case the section on where the position points describes. Engine error messages differ across browsers and often omit a position, so the location is computed independently and points at a reasonable spot to start looking. Fix the first error and re-check — a single stray character often cascades into several apparent problems.

Common JSON mistakes

JSON is stricter than the JavaScript object literals it resembles. These are the errors that trip people up most often:

• Trailing commas: a comma after the last item in an object or array is valid in JavaScript but not in JSON.
• Single quotes: JSON strings and keys must use double quotes. 'value' is invalid; "value" is correct.
• Unquoted keys: every object key must be a quoted string, so { name: "x" } must become { "name": "x" }.
• Comments: JSON has no comment syntax. // and /* */ will cause a parse error.
• Special numbers: NaN, Infinity and -Infinity are not valid JSON numbers.
• Wrong quote characters: “smart quotes” pasted from a word processor look like quotes but are different characters and will not parse.

Where the reported line and column point

The position is not where you left something out. It is where the parser first met something that cannot legally be there, and those are usually different places. In the object below, line 3 is missing the comma that should end it — and the tool reports line 4, column 3, the opening quote of the next key. Nothing was wrong until that quote arrived: the document could legally have ended after line 3, so the parser only learns of the omission when it meets something that is neither a comma nor a closing brace.

{
  "id": 42,
  "name": "widget"
  "price": 9.99
}

• A missing comma is reported at the first character of whatever comes next, which in indented JSON like the above is the following line — so read the line named together with the line above it.
• A trailing comma is reported at the closing brace or bracket: line 3, column 1 for an object whose last pair sits on line 2. The comma promises another pair and the brace is what breaks the promise.
• An unterminated string is usually reported at the end of the line it opened on rather than at the opening quote, because the next quote on a later line may close it somewhere else instead. A line break cannot appear inside a JSON string, so the break is the first character that cannot be there.
• Line 1, column 1 on a document that looks perfect usually means a byte-order mark. Some editors write one when saving as UTF-8; it is invisible, it sits before the opening brace, and JSON has no place for it.

And where the tool can work out no position at all, it reports the failure without one rather than naming a coordinate it has guessed. A confident line and column pointing at perfectly good syntax would send you looking in the wrong place, which is worse than being told only that the document does not parse.

What formatting changes, and what it keeps

For almost every document the answer is whitespace and nothing else. But the tool does not edit your text: it parses it into real values and writes those values out again, and five things do not survive that round trip. None of them is a fault in the tool — each is what the JSON specification says a number or an object is — and each is worth knowing before you paste the output back over your original.

• The same key written twice: only the last of the two survives, because an object cannot hold one key twice. RFC 8259 says software receiving an object with duplicate names behaves unpredictably, and another parser may keep the first instead, so which of the two you get is not something to rely on either.
• An integer longer than fifteen digits: JSON numbers are read as double-precision floating point, which holds every whole number up to two to the fifty-third exactly — a sixteen-digit figure — so a fifteen-digit integer always survives and a longer one may not. Paste 12345678901234567890 in and 12345678901234567000 comes out. Long database identifiers are the usual casualty: keep them as strings if you can.
• Exponent and trailing-zero forms are normalised: 1e3 comes back as 1000, and 1.50 as 1.5. That is the same number written the standard way.
• A magnitude outside what that format can hold comes back as something else entirely: 1e400 has no double-precision value and comes back as null, and 1e-400 comes back as 0. A long decimal fraction is rounded to the precision the format has, the same way a long integer is.
• An escape becomes the character it denotes: \u00e9 comes back as é, and an escaped surrogate pair as the emoji it spells. Both are the same string to any parser; one of the two spellings is simply shorter.

Key order is kept as you wrote it, with one exception worth knowing: a key that is nothing but digits, reading as a plain non-negative whole number under about four billion, is treated as an array index and comes back at the front of its object in numeric order, wherever you put it. Nothing else moves — no other key is reordered, and none is added or renamed. If any of this matters to you, minify rather than beautify and compare the result with your original character by character. That is the shortest way to see what the round trip did.

When the JSON you want is inside a string

Webhook logs, message queues and database columns very often carry a whole JSON document as a single string value, with every quote inside it escaped. The outer document is perfectly valid, so the tool beautifies it and reports it valid — and the part you came to read stays one long line of backslashes. Nothing has gone wrong: these are two documents, one wrapped inside a string of the other.

{
  "event": "order.created",
  "payload": "{\"id\":42,\"total\":19.99}"
}

Reading it therefore takes two passes. Format the outer document here, copy what sits between the quotes of the string you want, undo the escaping, and paste the result back in. The JSON string escape / unescape tool does that middle step: its unescape direction turns \" back into " and the line back into a document this page can format. If you control whatever produced the file, the better fix is upstream — send the payload as a nested object rather than as a string, and neither pass is needed.

One object per line is not one document

Log files, API exports and streaming endpoints commonly hold one complete JSON object per line; the format is called JSON Lines, or NDJSON. Every line is valid JSON on its own, but the file is not a JSON document, because a JSON document holds exactly one top-level value and this holds several, one after another with nothing joining them.

{"level":"info","msg":"started"}
{"level":"warn","msg":"retrying"}
{"level":"error","msg":"gave up"}

Paste that here and the tool reports line 2, column 1: the first object ended cleanly, and then a second one began where the document should have finished. There are two ways on from there. Format one line at a time, which is what you want when you are reading a single log entry. Or turn the file into one document — wrap the lines in square brackets and put a comma at the end of every line but the last — which is what you want when you are about to load the lot into something that expects an array.