What JSON formatting actually involves
JSON formatting is the difference between data your code can read and data that breaks at runtime. This guide explains the syntax rules, shows you how to validate and format JSON in the browser, and walks through the errors that cause most parsing failures. You will finish with a practical routine you can apply to any payload.
JSON, short for JavaScript Object Notation, is a text format for exchanging structured data. It looks like JavaScript object literals but is stricter. Two systems in different languages can both read it because the grammar is small and fixed.
That smallness is the point. There are six value types, one container for objects, one for arrays, and a handful of punctuation rules. Almost every JSON error traces back to breaking one of them.
JSON syntax rules you cannot bend
Objects, arrays and values
An object is a set of key-value pairs wrapped in braces. A key is always a string in double quotes. A value can be a string, number, boolean, null, another object, or an array.
An array is an ordered list in square brackets. Items are separated by commas. Arrays can hold mixed types, though mixing them usually signals a design problem downstream.
{
"orderId": "A-1042",
"items": ["keyboard", "cable"],
"shipped": false,
"weightKg": 1.4,
"notes": null
}
Strings, numbers and the null value
Strings use double quotes only. Single quotes are not valid JSON, even though they work in JavaScript. Escape a double quote inside a string with a backslash.
Numbers follow a narrow pattern: an optional minus sign, digits, an optional fraction, an optional exponent. Leading zeros are invalid. NaN and Infinity are not numbers in JSON; represent them as null or a string.
null is a real value meaning "no value". It is not the same as an empty string or a missing key. That distinction matters when you write validation logic.
Punctuation and encoding
Commas separate items. No comma follows the last item in an object or array. Colons separate keys from values. Whitespace between tokens is ignored, which is why the same data can be minified or pretty-printed without changing its meaning.
Text must be valid Unicode. Most tooling expects UTF-8. If you paste a file with a different encoding, you may see replacement characters where accented letters should be.
What JSON does not support
JSON has no comments, no trailing commas, no date type, no undefined, and no functions. Dates travel as strings, usually in ISO 8601 form, and it is the reader's job to parse them. If you need comments in configuration, that is a different format's job.
How to format and validate JSON in five steps
- Copy the raw text. Take the exact payload from your logs, API response, or file. Do not retype it; retyping introduces characters that were never there.
- Paste it into a formatter. A browser-based JSON formatter parses the text and reprints it with consistent indentation. Nothing is uploaded when the tool runs client-side.
- Read the error message. A parser reports the position of the first failure. Fix that one, then re-run. Parsers stop at the first problem, so later errors stay hidden until earlier ones are gone.
- Check the data types. Formatting proves the syntax is valid, not that the values are right. Confirm that numbers are numbers, booleans are unquoted, and dates follow the shape your code expects.
- Minify before shipping. Pretty-printed JSON is easier to read but larger. Minify for transport, keep the readable version for debugging.
A formatter catches syntax. It does not catch a misspelled key or a value in the wrong field. Those are schema problems, and you need a separate check for them.
Common JSON errors and how to fix them
Trailing commas
This is the single most frequent cause of a parse failure. A comma after the final member of an object or array is invalid.
{
"retries": 3,
}
Remove the comma after 3. The same rule applies to arrays: [1, 2, 3,] is invalid.
Single quotes and unquoted keys
JavaScript developers write {name: 'Ada'} and it works in a script. In JSON it fails twice: the key is unquoted and the value uses single quotes. Both need double quotes.
Unescaped characters inside strings
A literal newline inside a string breaks the document. Use \n instead. The same applies to tabs, and to backslashes in Windows file paths, which must be doubled.
Watch for smart quotes pasted from a word processor. They look like quotation marks but are different characters, and parsers reject them.
Mismatched brackets
Deeply nested objects are hard to scan by eye. A missing closing brace at the end of a large payload is easy to miss. An editor with bracket matching, or a formatter that fails at a specific line, narrows it down fast.
Numbers quoted as strings
"price": "19.99" is valid JSON but wrong for arithmetic. If your code sums that field, it will either fail or concatenate text. Decide the type when you design the payload, and keep it consistent.
How do you validate JSON quickly?
Paste the text into a browser-based validator. It parses the document and reports either success or the exact position of the first syntax error. Because the parsing happens locally in your browser, the data never leaves your machine. That makes it suitable for configuration files and test payloads, though you should still avoid pasting credentials or personal data into any online tool.
That paragraph is deliberately short: validation is a mechanical check, and the answer rarely needs more than a sentence once you know what the parser is telling you.
Formatting versus validating: two different jobs
Formatting changes whitespace. It makes the structure visible by indenting nested objects and putting each key on its own line. A formatter will refuse to run on invalid input, which is why people use it as a rough validator.
Validation checks grammar. A validator confirms the document follows the JSON specification. It says nothing about whether the fields match your application's expectations.
You need both, plus a schema check if the data crosses a system boundary. For quick debugging, a formatter that fails loudly is usually enough. For anything automated, validate the schema too.
Minifying and pretty-printing trade-offs
Pretty-printed JSON uses indentation and line breaks. It is readable and diff-friendly, which matters when config lives in version control.
Minified JSON strips all optional whitespace. The payload gets smaller, and for large API responses the saving is real. The trade-off is that a human cannot read it, so keep a formatted copy for debugging.
Indentation width is a style choice. Two spaces is common in JavaScript projects; four spaces appears in many others. Pick one per project and let the formatter enforce it, so diffs stay clean.
JSON in everyday workflows
Configuration files, API requests, log entries and test fixtures all lean on this format. A consistent habit pays off: format before you commit, validate before you deploy, and minify only at the transport layer.
If you work with several data formats, a broader set of browser-based utilities covers conversion and inspection tasks without installing anything. Everything runs locally, so there is no upload step and no account to create.
One honest limitation: a browser tool cannot see your server, your database, or your schema. It can tell you the document is syntactically valid. It cannot tell you the document is correct for your use case.
FAQ
What is the most common JSON syntax error?
Trailing commas. A comma after the last member of an object or array is invalid, and it appears constantly when hand-editing. Single quotes around strings and unquoted keys are close behind. All three are caught immediately by any parser, which reports the position of the first failure.
Can JSON have comments?
No. The specification does not include comments, and parsers reject them. If you need annotated configuration, use a format that supports comments. Alternatively, keep a separate documentation file alongside the JSON and describe each field there, which avoids the temptation to add inline notes.
Is JSON the same as a JavaScript object?
No. JSON is a text format with stricter rules. JavaScript object literals allow single quotes, unquoted keys, trailing commas and comments. JSON allows none of those. Valid JSON is usually valid JavaScript, but the reverse is not true, which is why copied code often fails to parse.
Why does my JSON fail only sometimes?
Intermittent failures usually come from the data rather than the structure. A user-entered string containing a quote or a newline breaks an otherwise valid document. Escape user input before you build the payload, and validate the assembled result rather than assuming it is safe.
Does formatting change the data?
No. Whitespace between tokens carries no meaning, so a formatted document and its minified twin represent identical data. The bytes differ; the parsed value does not. You can switch between the two freely without any risk of altering keys, values or ordering.
Getting JSON formatting right
Good JSON formatting comes down to three habits: know the syntax rules, validate before you ship, and keep a readable copy for debugging. Most failures are punctuation, not logic, and a parser will point at the exact character that broke.
Run your payload through a formatter, fix the first error, and repeat until it parses. Then check the types and the schema, because a valid document is not automatically a correct one. That routine handles nearly everything you will meet in day-to-day work.