JSON5 Validator
Well-formed or not, and exactly where it goes wrong when it is not.
JSON5
Result
Paste a JSON5 document to check it.
What "valid" means for a format built to be forgiving
JSON5 is deliberately more permissive than JSON — comments, unquoted keys, trailing commas and single-quoted strings are all legal, exactly the things a strict JSON parser rejects. That makes "is this valid JSON5" a genuinely different question from "is this valid JSON": a document can be perfectly good JSON5 and still fail if you ever need it as strict JSON, which is the case JSON5 to JSON exists to check separately.
This page runs the real json5 parser — the reference implementation, not a regular expression standing in for one — so a document either parses or it does not, the same way it would inside whatever tool actually reads your config file. When it fails, the error carries a line and column, because "invalid JSON5" with no location is not something you can act on in a 200-line file.
A document can be syntactically perfect and still be the wrong shape for whatever is going to read it — missing a field a loader expects, say. This page checks syntax, the thing the JSON5 specification actually defines. It has no way to know what your particular consumer requires beyond that.
Checking a document
- Paste the document – Comments, unquoted keys, trailing commas and single-quoted strings are all fine — that is the point of the format.
- Read the result – A green check with size, top-level key count and nesting depth for a document that parses; a red result with a line and column for one that does not.
- Try the invalid sample – It demonstrates a real, common mistake and how the error reads — worth doing once so you recognise the shape of the message later.
A document that parses here can still fail elsewhere if the thing reading it expects strict JSON — trailing commas, unquoted keys and single quotes are all valid JSON5 and all rejected by JSON.parse. Run it through JSON5 to JSON if that is the actual question.
A real mistake, and how the error reads
The invalid sample on this page — an unquoted key starting with a digit, which is legal in almost no context and easy to miss in a config file someone hand-edited.
{
subscriber: 'SUB-1001',
5g_enabled: true,
}JSON5: invalid character '5' at 3:3 // line 3, column 3 - the unquoted key // cannot start with a digit
When you need this
A config file a build tool refuses to load
Babel, webpack and similar tools read JSON5-flavoured config, and their own error messages about it can be terse. Pasting the file here gets a parser error you can actually act on.
Checking a hand-edited file before committing it
A quick paste before git commit catches a stray comma or an unterminated string before it becomes a broken build for the next person who pulls.
Confirming a generated file is well-formed
Something that programmatically writes JSON5 — a codegen step, a config templating tool — can still produce broken output if a value contains an unescaped quote. This is a fast way to check the output before shipping it.
Teaching the difference between JSON5 and JSON
Paste the same document here and into JSON Validator — a file with a trailing comma passes one and fails the other, which is a quick, concrete way to see what JSON5 actually relaxes.
What this page does
- Runs the real json5 parser rather than a hand-written approximation, so the result matches what your actual tooling will do.
- Reports a genuine line and column on failure, not just "syntax error".
- A separate invalid-sample button demonstrates a real, common mistake without the page's own valid sample ever looking broken.
- Reports size, top-level key count and nesting depth for a document that passes — useful for a quick sanity check on a generated file.
- Runs entirely in your browser, so a config file carrying real credentials or internal hostnames is never sent anywhere.
Questions people actually ask
This says my document is valid, but my build still fails. Why?
This page checks syntax against the JSON5 specification, not against whatever schema or shape your specific tool expects — a missing required field or an unexpected value type is a valid document by JSON5's own rules. If the failure is specifically about strict-JSON compatibility, try JSON5 to JSON instead, which will surface a trailing comma or unquoted key as the actual problem.
Why does a trailing comma pass here and fail in JSON.parse?
Because a trailing comma after the last item is explicitly legal in JSON5 and explicitly illegal in strict JSON — this is one of the format's deliberate relaxations, not a bug in either parser. See the specification for the full list of what JSON5 permits over JSON.
Does this check for duplicate keys?
No — like JSON, JSON5 does not forbid a repeated key, and the parser keeps whichever occurrence comes last, silently. If duplicate keys in a hand-edited file are a concern, that is worth checking for separately; this page reports what the JSON5 grammar itself considers valid.
What is the line and column counting from?
The document as you pasted it, 1-based — line 1 is the first line, column 1 is the first character. If the file has a shebang line or a byte-order mark pasted in by accident, count that as line 1 too.
Related tools
Specifications and references
- JSON5 — a superset of JSON – What is relaxed relative to JSON, and why
- The formal JSON5 grammar – The precise syntax the parser checks against
- MDN — Identifier – The JavaScript identifier rules JSON5 unquoted keys follow