JSON Validation Guide: How to Check and Fix Broken JSON

By ZeroFee Tools · October 4, 2026 · 6 min read

A single trailing comma can take down an API integration, and the error message you get is usually cryptic. A JSON validator checks your text against the strict JSON rules and explains failures in plain English. The free validator on ZeroFee Tools reports the exact line and column of each error, plus automatic fix hints for the most common mistakes.

Valid documents get a green confirmation showing their type, whether object, array, string, or number, along with the key or item count. Once your JSON passes, the JSON formatter makes it readable, and the JSON minifier compresses it for shipping, and because validation is instant and local, it fits naturally into a tight edit-check loop: paste, validate, fix, repeat until green.

What makes JSON valid or invalid?

Valid JSON follows a strict grammar: double-quoted strings and keys, no trailing commas, no comments, and balanced brackets and braces. Any deviation fails parsing. The validator applies these exact rules, so JSON that passes here will parse in every browser, server, and API.

JSON is deliberately stricter than the JavaScript it resembles. That strictness is the point: a format every language can parse identically cannot afford ambiguity. So keys must be double-quoted, strings must use straight double quotes, the last item in any object or array cannot carry a trailing comma, and comments are forbidden entirely.

The validator enforces the same rules as JSON.parse in your browser, which means a green result is a real guarantee, not an approximation. It also tells you what you have: the success message names the document type and counts keys or items, which is a quick sanity check that you pasted the whole payload and not a truncated fragment. When the result is red, the hints box translates the parser complaint into the likely fix, starting with the four usual suspects covered below.

One more structural rule worth knowing: a JSON document holds exactly one top-level value. Two objects pasted back to back are not valid JSON, even if each is valid alone. When an API streams multiple objects, each line is its own document, a format called JSON Lines, and each line must validate separately.

Why is a trailing comma invalid in JSON?

The JSON specification simply does not allow trailing commas, unlike JavaScript object literals. A comma promises another item, so a parser that finds } or ] instead reports an error. Remove the comma after the last item in every object and array, and the document validates.

Trailing commas are the number one JSON killer because JavaScript developers write them reflexively. In JS, an object ending with a comma after its last property is fine; in JSON it is a syntax error. The validator fix hints specifically scan for this pattern and tell you which line to check.

The same habit causes trouble in reverse: hand-editing a JSON config, you delete the last entry but leave its comma behind, and now the second-to-last item illegally trails one. Whenever validation fails right after an edit, check the commas first. A regex tester can help hunt stray commas across a large file with a pattern that finds commas sitting directly before a closing brace or bracket.

Editors can prevent this class of error entirely: most code editors flag trailing commas in JSON files as you type. If you edit configs often, turn on JSON validation in your editor so mistakes surface before they ever reach the browser.

Why does pasting a JavaScript object literal break JSON?

Object literals allow trailing commas, unquoted keys, single-quoted strings, and comments, but JSON allows none of these. Copying code straight from a JS file into a .json file or API body therefore fails. Quote the keys, switch to double quotes, drop the comments, and remove trailing commas.

This is the classic copy-paste trap. You grab a config object from documentation or a teammate code snippet, paste it into the validator, and get a wall of red. The four conversions above fix nearly every case. Smart quotes are a sneakier variant: text copied from Word, PDFs, or chat apps uses curly quotes that look right but are illegal in JSON; replace them with straight double quotes.

A useful workflow: validate first, then format. The validator hints identify the class of problem, you fix it, and the JSON formatter pretty-prints the now-valid document. For tabular data that needs to become JSON, the JSON to CSV tool runs the opposite direction once your structure is sound.

When the errors feel endless, reduce the document: delete half, validate, and see if the remainder passes. Binary search on a broken file finds the offending section far faster than reading every line, especially in generated payloads.

How to validate JSON online in 4 steps

1. Paste your JSON. Drop the document into the input box, or press Sample to load a valid example and see what success looks like.
2. Press Validate. The tool parses your text with strict JSON rules; there are no lenient modes that might hide problems.
3. Read the result. Green confirms validity and shows the type plus key or item count. Red shows the line and column of the error with a surrounding snippet.
4. Follow the fix hints. The hints box names the likely culprit, such as a trailing comma or single quotes. Correct it and validate again.

5 practical JSON validation tips

• Validate before you format. Formatting invalid JSON just fails; validating first tells you what to fix, then formatting shows the clean result.
• Check commas after every edit. Hand-edited configs break most often at commas: a deleted entry leaves one behind, or a new entry misses one.
• Beware smart quotes. Curly quotes from Word, PDFs, or chat apps look correct but are illegal. Replace them with straight double quotes.
• Confirm the whole payload arrived. A green result with an unexpectedly low key count means you may have pasted a truncated fragment.
• Test with the strictest parser. If it validates here with native JSON.parse rules, it will parse anywhere; lenient validators can give false confidence.
• Save known-good samples. Keep a small library of valid payloads for your APIs; validating a suspect document against a working example quickly shows what changed.

Frequently asked questions