Free JSON5 Validator - Comments, Unquoted Keys & Trailing Commas

JSON5 is a documented superset of JSON designed for humans writing configuration by hand. It keeps JSON's object and array model, then relaxes the parts that make RFC 8259 painful in a text editor: comments, unquoted keys, trailing commas, single-quoted strings, hexadecimal numbers, and a handful of extra number forms. A JSON5 validator answers a narrower question than a linter: does this text parse as JSON5? This page uses the official JSON5.parse implementation. It does not execute the document. There is no eval.

JSON itself (ECMA-404 / RFC 8259) is a data interchange format. Production APIs, JSON.parse in browsers, and most language standard libraries reject trailing commas and comments on purpose. Teams still adopt JSON5 for .babelrc-style configs, hand-edited fixtures, and documents that need inline notes. The mistake is shipping that dialect to a consumer that only speaks strict JSON. This tool always shows both results so you see the dialect line instead of discovering it in CI.

The default document {a:1,} is valid JSON5 and invalid JSON. The unquoted key a and the trailing comma after 1 are legal in JSON5 and illegal in RFC 8259. If that default ever parsed as JSON on this page, the tool would be lying about the dialect. Keep it until you understand the split, then paste your own file.

Conversion via JSON.stringify is a convenience, not a round-trip pretty-printer. Comments disappear. Original key quoting is lost. Infinity and NaN become null. Use the conversion only when you need a strict JSON payload. If you intended strict JSON from the start, validate on the JSON validator or format on the JSON formatter.

Checking a JSON5 document here takes under a minute:

1. Paste your JSON5 - Copy a config file, fixture, or snippet into the left panel. Click Sample to restore the default {a:1,} if you want the dialect contrast again.
2. Read JSON5 versus JSON - The right panel reports whether JSON5.parse succeeded, then whether JSON.parse accepted the same text. JSON5 succeeds on the default; strict JSON fails.
3. Copy a JSON.stringify conversion if you need RFC 8259 - When JSON5 parses, a converted object appears. Conversion drops comments and is not a lossless pretty-printer of original formatting.
4. Copy or clear - Copy the converted JSON or the validation report. Clear erases the editor and the local draft stored under json5-validator-input. Nothing is uploaded.
5. Fix JSON5 errors from the parser message - If JSON5 itself fails, the error appears under the input. Fix that first. A document that is invalid JSON5 is also invalid JSON.

Desktop users can drag the unique json5-validator-split-track handle to resize the panels. Fullscreen expands the result. Panel width is stored separately from the draft so a 60/40 layout survives a refresh without colliding with other tools on this site.

The default sample is the shortest document that makes the dialect obvious:

{a:1,}

{
  "a": 1
}

That converted document is RFC 8259. It is also a different artifact: comments are gone, key quotes are added, and spacing is whatever JSON.stringify emits. Do not treat conversion as "JSON5 but pretty." Treat it as a new JSON document derived from the parsed value.

JSON5 is not "JSON with one extra comma." If you rely on the dialect, you should know which extras parse here and which extras still fail:

• Unquoted keys that are valid ECMAScript identifiers: {a:1} parses. Keys with spaces or hyphens still need quotes.
• Trailing commas in objects and arrays: {a:1,} and [1, 2,] parse. A hanging comma after nothing still fails.
• Single-quoted strings: {a:'ok'} parses. JSON requires double quotes.
• Line comments and block comments: // note and /* note */ are skipped. JSON forbids both.
• Hexadecimal numbers: 0xFF parses as 255. JSON has no hex form.
• Leading plus, leading or trailing decimal points where JSON5 allows them: +1, .5, 5. can parse. JSON is stricter about number tokens.
• Infinity and NaN: JSON5 allows these tokens. They are not JSON numbers. See the conversion caveat below.
• Multiline strings using escaped newlines, following the JSON5 specification rather than JSONC-only extensions some editors invent.

JSON5 is also not TypeScript, not YAML, and not JSONC. Type annotations fail. YAML indentation is a different language. VS Code JSONC may allow trailing commas in some settings files while still rejecting unquoted keys - do not assume one comment-friendly dialect equals another.

JSON5 allows Infinity, -Infinity, and NaN. Those tokens are IEEE-754 values in JavaScript, not JSON numbers. After a successful JSON5 parse, this page runs JSON.stringify on the value. The JSON spec has no Infinity token, so stringify turns those values into null. If you needed the token to survive, quote it as a string in the source or keep the JSON5 document and a JSON5 parser on both ends.

Duplicate keys follow JavaScript object semantics: later keys win. Large integers become IEEE-754 doubles, so integers beyond 2^53-1 are not exact. Those are language limits, not extra lint rules. This validator will not warn about duplicate keys or unsafe integers. It only reports whether parse succeeded.

Nothing in the document is executed. JSON5.parse builds a value. It does not run methods, import modules, or evaluate expressions inside strings. If someone pastes alert(1) as a key or value, it stays data. That is intentional.

If your file is comment-only JSONC, stripping comments and then using the JSON validator may be enough. If you use unquoted keys or trailing commas as a habit, you are in JSON5 territory and should say so in the filename or the docs.

JSON5 shows up where humans edit files and machines only read them after a dedicated loader: Babel-family configs, some bundler option files, and internal fixtures that a test harness parses with the JSON5 package. It is a poor choice for HTTP response bodies, browser Response.json(), localStorage payloads you will JSON.parse later, and any public API contract. Those surfaces standardized on RFC 8259 because every language already ships a JSON parser and none of them agree on JSON5.

Filename signals help. .json5 tells a teammate to use a JSON5 parser. .json with comments inside is a lie that will fail in CI the first time someone runs a strict formatter. If you must keep comments in a .json path, you are in JSONC territory and should use a JSONC stripper, not this page's conversion (which drops comments by going through a JS value).

Editors complicate the story. VS Code "JSON with Comments" is not JSON5. IntelliJ may allow trailing commas in some JSON dialects. Prettier and jsonlint will reject the default sample. Align the validator with the parser your runtime actually uses. This page is the JSON5.parse check, not a claim that your next pipeline step speaks JSON5.

When you convert, read the output. Nested objects pick up quotes. Arrays lose trailing commas. Hex 0x10 becomes 16. A comment above a key vanishes without a hole in the tree. If a code review needs the comment, keep the JSON5 source in git and generate JSON at build time instead of editing the converted dump by hand.

All JSON5 parsing and JSON comparison runs in your browser. The draft is stored only under the unique localStorage key json5-validator-input for up to 30 days, with panel width under json5-validator-panel-width. Neither key is shared with the JSON formatter or the strict JSON validator. Click Clear to erase the draft immediately. Config files with secrets are still better kept off shared machines, but they are not uploaded from this page.

Because this is parse-only, pasting a document cannot run code through this tool. Treat converted JSON as data you still need to handle safely in your own application.