JSON Formatter & Validator Pretty Print, Minify, and Check JSON Syntax

What JSON actually is

JSON, short for JavaScript Object Notation, is a plain text format for representing structured data. It was standardised in the mid-2000s and is now defined by two documents: IETF RFC 8259 and the ECMA-404 standard. Those two documents say the same things in slightly different words, and together they describe a syntax so small that a full JSON parser can fit in a few hundred lines of any modern programming language.

The format's popularity comes from that simplicity. It is easy to read, easy to generate, easy to parse, and it does not depend on a particular language, operating system, or vendor. Almost every public API you will encounter returns JSON. Almost every configuration file for a modern tool is either JSON or a close cousin of it. And almost every database that stores semi-structured data has a native JSON column type.

The formatter on this page does not add anything to JSON. It reformats a document that already exists, or it tells you why a document that is not valid cannot be parsed. That is the whole scope. There is no schema validation, no transformation, no rewriting of the data. What comes out is the same content you put in, either with or without indentation.

The six data types in JSON

Every value in a JSON document is one of six things, and no others are permitted. Understanding the six types and their exact spellings is enough to write valid JSON almost every time.

Strings are sequences of characters enclosed in double quotes. The double quote character is mandatory. Single quotes, backticks, and unquoted strings are not valid JSON, even though some languages accept them in object literals. Inside a string, a small number of escape sequences are available, including \" for a literal double quote, \\ for a backslash, and \n for a line break. Any Unicode character can appear directly, or via a \uXXXX escape.

Numbers are written in decimal. Integers, negative numbers, fractions, and scientific notation are all fine: 42, -7, 3.14, and 1.5e3 are all valid. What is not valid: leading plus signs, leading zeroes (except for the number zero itself), hexadecimal notation, Infinity, NaN, and quoted numbers. If a value is meant to be a number, do not wrap it in quotes.

Objects are unordered collections of key-value pairs enclosed in curly braces. Every key must be a string in double quotes, and every key must be followed by a colon, then a value, then a comma if another key follows. The comma after the last pair must not be present.

Arrays are ordered sequences of values enclosed in square brackets. Values are separated by commas, with no trailing comma after the last value. Arrays can contain any of the six types, including other arrays and objects, which is how nested structures are built.

Booleans are the two literal values true and false, always in lowercase. True, TRUE, and quoted versions like "true" are all invalid as boolean values.

Null is written as null, again in lowercase. It represents the absence of a value. Quoting it, or capitalising it, produces a string or a parse error rather than a null value.

Format and minify, and when to use each

Formatting and minifying are the two operations this tool performs, and they are opposites.

Pretty printing inserts newlines and indentation so the structure of the document is visible at a glance. Every opening brace, bracket, or key-value pair sits on its own line, and nesting is shown by increasing the indent depth. The result is longer than the input but far easier for a person to read, review, and debug. This is the form you want when you are working with the document yourself.

Minifying removes every character that the parser does not need. Newlines, indentation, and spaces around punctuation are all stripped. The result is the smallest possible valid representation of the same data. It is unreadable to a person but smaller over the wire, which matters when a payload is sent to thousands of clients or stored in a database for years.

Three indentation options are available: two spaces, four spaces, and a single tab character. Two spaces is the modern default used by GitHub, most npm packages, and most REST APIs. Four spaces is common in Python ecosystems and on high-contrast displays. Tabs let the reader's editor decide the visual width, which suits developers who have strong preferences about how much indentation they want to see. The choice has no effect on the meaning of the document, only on its appearance.

Common syntax errors that break a document

The same handful of mistakes account for the vast majority of invalid JSON documents. Each one produces a fairly specific error message from any compliant parser, and each is easy to fix once you know what to look for.

Trailing commas. A comma after the last key in an object or after the last value in an array is illegal in JSON. The mistake comes from JavaScript, where trailing commas are legal in object and array literals, and from Python, which accepts them in tuples and lists. JSON does not. Remove the comma after the last element.

Single quotes. JSON requires double quotes around strings and keys. Single-quoted strings and unquoted keys are legal in JavaScript object literals, in Python dictionaries, and in the JSON5 extension, but not in JSON itself. Replace every single quote with a double quote.

Comments. JSON has no comment syntax at all. Neither line comments starting with // nor block comments wrapped in /* */ are permitted. If you need to keep notes alongside a JSON document, put them in a separate file or use a schema with a description field.

Unescaped control characters. A raw tab, newline, or carriage return inside a string value is illegal. If you need one of those characters, escape it with the appropriate sequence. A literal newline is written as \n, a tab as \t, and a carriage return as \r.

Missing or mismatched brackets. Every opening { must have a matching }, and every opening [ must have a matching ]. A single missing brace anywhere in a large document usually produces an error near the end of the file, because that is where the parser realises nothing closes the structure it is still inside.

Numbers as strings or vice versa. "42" and 42 are different values. If a consumer expects a number and gets a quoted string, or vice versa, the document may parse but downstream logic will fail. Type mismatches are a common cause of subtle bugs in JSON-based APIs even when the JSON itself is technically valid.

A worked example with a real payload

Consider a small API response that a developer has hand-written. It contains four common errors: single-quoted keys, one unquoted key, a trailing comma in an array, and a trailing comma on the last object property.

Feeding that into any compliant parser fails on the first line, because the key 'status' uses a single quote. The parser cannot even reach the later errors until the first one is fixed. Once the single quote is replaced with a double quote, the parser advances until it hits the unquoted key code, which also fails. Fixing that reveals the trailing comma after "deploy", inside the array. And fixing that reveals the trailing comma after the closing brace of the permissions array.

The corrected document is four characters shorter and eleven characters different, and it parses cleanly. Once pretty printed, it is easy to scan the structure of the response, spot the user ID, and confirm that the permissions list contains the three expected entries. Once minified, the same document fits on a single line of about a hundred and thirty characters, which is the form it would be sent over the wire.

That progression is why a formatter is useful. It does not just make a document pretty. It surfaces the errors that keep you from working with the data at all, and it produces the two different representations that two different contexts require.

Everyday uses for a JSON formatter

JSON formatting comes up in more places than the name suggests, and the tool is useful in all of them.

Debugging an API response. A server returns a wall of minified JSON and you need to see what is inside. Pasting it into the formatter gives you the full structure in a few seconds, with all the nested objects and arrays laid out so you can find the field you were looking for.

Reviewing a configuration file. Modern applications use JSON for settings, service definitions, package manifests, and cloud infrastructure templates. When a config file stops working after an edit, formatting it and checking for syntax errors is the fastest way to find the mistake.

Shrinking a payload for storage or transport. If you are storing JSON in a key-value store, sending it through a message queue, or embedding it in a URL parameter, minification reduces the byte count with no loss of information. On large datasets the saving is often twenty to forty per cent of the original size.

Preparing data for documentation. Examples in API docs and README files are easier to read when they are pretty printed, and easier to keep in sync when the indentation is consistent. A quick pass through the formatter before pasting an example keeps documentation tidy.

Checking a document before publishing. Structured data embedded in a web page, such as JSON-LD for search engines, must be valid. Formatting it and checking for parse errors before publishing catches mistakes that would otherwise be silently ignored by search engines.

Why JSON is not the same as a JavaScript object

The name JSON stands for JavaScript Object Notation, and the syntax is modelled on JavaScript object literals. That resemblance is the source of a great deal of confusion, because the two are not the same thing and the differences matter.

A JavaScript object literal can contain functions, can reference variables, can use single-quoted or unquoted keys, can include trailing commas, can include comments, and can contain the special values undefined, NaN, and Infinity. JSON permits none of those. A JavaScript object is a live value in memory, with methods and prototypes and mutable state. JSON is a piece of text, with no behaviour and no identity beyond the characters that make it up.

The practical consequence is that passing a JavaScript object to a JSON validator is not guaranteed to work, even if the object looks valid on screen. JSON.stringify() exists precisely to convert a JavaScript object into valid JSON text, and it handles the differences by dropping functions, converting undefined to null in some positions, and quoting keys. If you have a JavaScript object you want to validate, run it through JSON.stringify() first, then paste the result.

The same applies in reverse. If you need to use a JSON document inside JavaScript, parse it with JSON.parse() rather than evaluating it as code. Evaluation is dangerous because a malicious JSON document could contain executable JavaScript, whereas parsing is safe because the format has no executable constructs. Every modern JavaScript environment provides JSON.parse() and JSON.stringify() in the standard library.

Where this tool stops

This is a formatter and validator, not a JSON toolkit. It checks syntax, produces a pretty printed or minified representation of the same content, and reports the position of the first error it encounters. It does not check the document against a schema, does not verify that fields are of the expected type, does not compare two documents, does not diff versions, and does not transform content in any way.

It also does not handle the newer JSON-adjacent formats. JSON5, JSONC, JSON Lines, NDJSON, and JSON with comments are all separate specifications and each is handled by its own tooling. If you have a document in one of those formats, convert it to strict JSON first, then paste it here.

Finally, this tool processes documents in the browser's own parser, which is defined against RFC 8259. In the rare case where a document parses here but fails in an older server-side parser, the difference is almost always a library-specific quirk rather than a fault in the document. If you are shipping JSON to a system that uses a very old parser, test against that parser before assuming compatibility.

For most everyday work, though, the tool does one thing well: it tells you whether a piece of JSON is valid, shows you why if it is not, and produces the formatted or minified form you need to move on with the work.

Sources

The syntax rules and error descriptions on this page come from the two formal specifications for JSON and the reference documentation maintained by the organisations that produce them. The sources below are the ones a reader can verify independently.