Paste minified JSON →get indented, syntax-highlighted output. Auto-fixes trailing commas and unquoted keys. 100% client-side.
Waiting for input...
JSON (JavaScript Object Notation) is the standard data interchange format for web APIs, config files, and data storage. A JSON formatter takes minified or poorly-formatted JSON and re-indents it with consistent spacing, making it human-readable.
JSON tokens consist of:
{ }. Keys must be strings (double-quoted). Values can be any JSON type.[ ]. Elements can be of mixed types.true, false, or null.Copy formatted JSON into your editor, documentation, or PR description. This formatter auto-fixes the most common JSON syntax errors: trailing commas after last elements, single-quoted strings, and unquoted property names.
All formatting happens entirely in your browser. Your JSON is never uploaded to a server or used for AI training.
JSON defines exactly one number type. There is no integer, no decimal, no 64-bit type — and every parser that matters reads numbers as IEEE 754 double-precision floats. That gives you 15 to 17 significant digits and no more.
So IDs drift. Paste 1234567890123456789 through a formatter built on a JavaScript parser and it comes back as 1234567890123456800. Twitter/X, Discord, and Snowflake-style identifiers all live in this range, which is precisely why those APIs return IDs as strings. Pass a raw numeric ID through any float-based parser and the value you get out is not the value you put in — it will match no row in the database, and the failure is silent.
Money has the same problem from the other direction. 0.1 + 0.2 evaluates to 0.30000000000000004 in every double-based parser, so storing currency as a JSON number invites rounding drift that surfaces months later in a reconciliation. Store amounts as minor units — cents as an integer — or as decimal strings.
Two smaller number rules that catch people: leading zeros are illegal, so {"id": 007} is invalid JSON and so are +1 and .5. A number may begin with a digit or a minus sign, and a decimal point must be followed by at least one digit.
Duplicate keys are permitted and resolved silently. Nothing in the spec requires a parser to reject {"a": 1, "a": 2}. JSON.parse keeps the last value, so a config file that defines a key twice behaves as though the first definition never existed — and a formatter that round-trips through a parsed object destroys the evidence. When two systems both generate the same config, this is how a setting disappears with no error anywhere in either pipeline.
A trailing comma is not the same failure as a missing comma. Missing punctuation stops the parser at an exact character, which is easy to fix. A trailing comma is subtler: the spec forbids it, but JSON5, JSONC, and JavaScript object literals all allow it. The same text is valid in your editor's settings.json and invalid the moment it crosses the wire. VS Code configuration files and tsconfig.json are the main reason people paste something that looks correct into a strict validator and get an error they cannot see.
Indenting two spaces per level inflates a payload by roughly 10–30%. For a config file that is irrelevant; for a response body served a million times a day it is not. That asymmetry is the whole reason APIs ship minified JSON while their documentation shows indented examples.
The bigger risk at the boundary is encoding, not whitespace. A file saved as UTF-8 with a byte order mark fails in parsers that do not skip the BOM, and the error surfaces as an unexpected character at position 0 — which reads like corruption rather than an encoding problem. The same content re-saved as UTF-16 fails almost everywhere. If a payload is rejected and looks perfect, check the first three bytes before you check the braces.
For logs, the practical alternative to pretty-printed JSON is NDJSON: one complete object per line, no enclosing array. It streams, it greps, and a truncated final line damages one record instead of invalidating the whole file. Format for humans when a human will read it; minify and stream when only a machine will.