How to Format and Validate JSON (Without Breaking It)

JSON looks simple until a missing comma takes down a deploy. Most JSON failures are not exotic: they are trailing commas, single quotes, comments, or a bracket that does not match. This guide covers what valid JSON actually allows, the errors you will see most often, and a reliable way to format and validate a payload.

What valid JSON allows

JSON has a very small grammar:

• A value is an object, array, string, number, true, false or null.
• Object keys must be double-quoted strings.
• Strings use double quotes; single quotes are not valid.
• Arrays and objects cannot have trailing commas.
• Comments are not part of the JSON specification.
• Numbers cannot be NaN, Infinity or hexadecimal.

That is basically it. The strictness is the point: every JSON parser in every language can agree on the same input.

The five errors you will hit most

1. Trailing commas

{
  "name": "Ada",
  "age": 36,
}

This is valid in JavaScript and in JSON5, but not in JSON. Remove the comma after the last property.

2. Single quotes

{ 'name': 'Ada' }

JSON only accepts double quotes. This usually happens when copying from Python or JavaScript by hand.

3. Unquoted keys

{ name: "Ada" }

Object keys must be strings in double quotes. This is another JavaScript habit that JSON does not share.

4. Comments

{
  // the user's name
  "name": "Ada"
}

JSON has no comments. If you need comments in a config file, use JSONC or YAML, but do not send comments to a JSON API.

5. Mismatched brackets

A missing } or ] often produces an error at the end of the file rather than where the mistake actually is. Formatting the document makes the missing level much easier to spot.

Why formatting matters

Minified JSON is efficient for machines but painful for humans. A formatted document:

• shows the structure at a glance;
• makes diffs readable in code review;
• helps you find a missing bracket or comma;
• gives you a stable shape to compare between two payloads.

If you are debugging an API response, paste it into a formatter before reading it. If you are comparing two versions, format both first, then diff them. Formatting removes whitespace noise and makes the real change visible.

Pretty print vs minify

Pretty printing adds indentation and newlines for readability. Minifying removes all optional whitespace for transport. They are the same data; choose based on the audience:

• Use pretty print for logs, documentation, test fixtures and debugging.
• Use minified JSON for request bodies and responses where bytes matter.

A formatter should let you switch between 2 spaces, 4 spaces, tabs and minified output without changing the values.

Finding errors with line numbers

The most useful error message is not “invalid JSON”; it is “unexpected token at line 4, column 3”. Modern parsers usually provide a position, but the message format varies by runtime.

A browser-based formatter can parse the document, report the line and column, and keep the output empty until the JSON is valid. That feedback loop is much faster than guessing which bracket is missing.

The JSON Formatter does exactly that: paste a payload, see the error position, then format or minify once it parses. Everything runs locally, so you can safely use it with production payloads.

JSON is not a JavaScript object

A JavaScript object literal can contain functions, undefined, single-quoted keys and comments. JSON cannot. The confusion is common because the syntax looks similar, but JSON is a data format, not a language.

If you need to turn JSON into a JavaScript value, JSON.parse handles that. If you need to turn a JavaScript object into JSON, JSON.stringify will:

• drop undefined and functions;
• convert dates to strings;
• throw on circular references;
• turn NaN and Infinity into null.

Knowing those rules prevents a whole class of “why did this field disappear?” bugs.

From JSON to other formats

Once a payload is valid, you often need it in another shape:

• JSON to CSV turns an array of objects into a spreadsheet.
• YAML to JSON moves configuration between the two formats.
• Diff Checker compares an old and new payload after both are formatted.

A practical checklist

1. Paste the payload into a formatter and fix syntax errors first.
2. Format both versions before comparing them.
3. Minify only when you are about to send the data.
4. Keep comments out of JSON; use YAML or JSONC for configs that need them.
5. Do not use JSON for secrets you would not put in a log.

JSON is strict on purpose. Once you know the handful of rules it enforces, most parser errors become obvious within seconds.