Utilify

JSON Validator

Validate JSON syntax online with clear error messages and line numbers. Free and private.

Built and maintained by Jay SooUpdated August 27, 2026

How to use JSON Validator

  1. 1
    Paste JSON

    Paste the JSON you want to validate.

  2. 2
    See results

    Validation runs as you type — valid or invalid with details.

About JSON Validator

JSON looks simple but is surprisingly easy to break — a missing comma, an unquoted key, a stray trailing comma, or a misplaced bracket can all turn valid-looking JSON into a parse error. The official JSON specification (RFC 8259) is strict: keys must be double-quoted, no comments are allowed, and trailing commas are forbidden. Relaxed variants like JSON5 or jsonc support these conveniences but produce output that is not standard JSON.

A dedicated validator gives precise, actionable error messages — including the character position of the problem — so you can fix syntax issues quickly rather than squinting at a wall of braces. Utilify's validator uses your browser's native JSON.parse, which guarantees the same behavior as the production JavaScript runtimes your code actually runs on. Everything runs locally; your payload never leaves the page.

The errors people hit most often are predictable. Single quotes instead of double quotes around strings and keys; a comma after the last element of an array or object; copying a JavaScript object literal (where unquoted keys are legal) and expecting it to be valid JSON; "smart" curly quotes pasted from a word processor; and an unescaped newline or backslash inside a string. Each of these produces a clear parse error here, positioned so you can jump straight to the offending character.

Validating is not the same as formatting. A formatter assumes the input is already valid and rearranges its whitespace; a validator decides whether the input can be parsed at all, and tells you exactly where it fails if not. Run the validator first when you are debugging a payload of unknown origin — an API response, a webhook body, a hand-edited config file — and only format once it parses cleanly.

One distinction worth keeping in mind: syntax validation is not schema validation. This tool confirms that your JSON is well-formed and parseable. It does not check that required fields are present, that a value is a number rather than a string, or that an enum holds an allowed value — those are JSON Schema concerns, a separate layer that runs on top of valid JSON.

Decoding JSON.parse error messages — what each one actually means

The error wording below is what V8 (Chrome, Edge, Node.js) produces — every message here was generated by feeding the broken JSON to the real engine. Firefox and Safari describe the same failures in different words, but the causes and fixes are identical:

Error messageWhat it usually meansThe fix
"Expected double-quoted property name"A trailing comma before } — or a key later in the object that isn’t double-quotedIf it’s the last property, delete the trailing comma; otherwise double-quote the key the parser stopped at
"Expected property name or '}'"A key that is single-quoted, unquoted, or wrapped in “smart” quotes from a word processorUse plain double quotes around every key
"Unexpected token 'u' … is not valid JSON"A JavaScript-only value like undefined (NaN gives the same error with 'N')Use null — JSON has no undefined or NaN
"Expected ',' or '}' after property value"A missing comma between two propertiesAdd the comma the parser stopped at
"Bad control character in string literal"A literal line break or tab inside a string valueEscape it as \n or \t
"Unexpected non-whitespace character after JSON"Content after the document ends — a // comment, or two JSON documents pasted togetherRemove everything after the closing brace
"Unexpected end of JSON input"The document stops mid-way: an unclosed brace or bracket, or a truncated API responseCheck the payload arrived complete and every { and [ is closed

Paste the broken JSON above and this page shows your own browser’s message plus the computed line and column — the position is usually more useful than the wording.

When to use JSON Validator

  • CI pipeline checks

    Validate JSON config files before deploys to catch syntax errors early.

  • Pre-processing webhooks

    Confirm payload is well-formed before passing to downstream parsers.

  • Documentation examples

    Verify JSON samples in API docs are actually parseable before publishing.

Frequently asked questions

What does the validator check?+

Strict JSON syntax per RFC 8259: matched braces and brackets, double-quoted keys, valid escape sequences, correct value types, and no trailing commas.

Does this support JSON5 or comments?+

No — JSON5 and JSON-with-comments (jsonc) are not standard JSON and will be reported as invalid.

My JSON looks fine but is reported invalid. Why?+

The usual culprits are single quotes instead of double quotes, a trailing comma after the last item, unquoted keys copied from a JavaScript object, or "smart" curly quotes pasted from a document.

Does it validate against a schema?+

No. This checks syntax only — whether the JSON is well-formed and parseable. Verifying required fields, value types, or allowed values needs JSON Schema validation, which is a separate step.

Is my data uploaded anywhere?+

No. Validation runs entirely in your browser with the native JSON.parse engine. Your payload never leaves the page.

Why does the same broken JSON show a different error in Firefox or Safari?+

This tool uses your browser’s own JSON.parse, and each engine words its errors differently — V8 (Chrome, Edge), SpiderMonkey (Firefox), and JavaScriptCore (Safari) describe the same failure in their own phrasing. This page reads whichever location format your engine provides: Chromium reports a character position (converted here to line and column), Firefox reports line and column directly, and when a message carries neither, only the raw error is shown.

Are duplicate keys valid JSON?+

Syntactically yes — RFC 8259 does not forbid {"a": 1, "a": 2}, so this validator accepts it. But behavior across parsers is not guaranteed; JavaScript keeps the last value (you get {"a": 2}). Treat duplicate keys as a bug in the producer even though they parse.

Related tools

From the blog