JSON5 to JSON

JSON5 relaxes four rules. Converting means undoing all four.

A config file written as JSON5 is usually fine to stay JSON5 forever — until something in the chain only speaks strict JSON. JSON.parse, most HTTP APIs, and plenty of older tooling reject exactly what makes JSON5 worth using: unquoted keys, single-quoted strings, a trailing comma on the last item, and // or /* */ comments. This page runs the real json5 parser and reprints the result as strict JSON, so all four are handled the way the format's own specification defines them, not by regular-expression guesswork.

Comments are the one thing this cannot carry across, and it is worth being direct about why: once the document is read into a value, a comment has already stopped existing — there is no field in the resulting object to put it in. If a comment explains something a future reader needs to know, copy it out before converting, the same limitation JSON5 Formatter states for the identical reason.

Long integers are the one place a naive read-then-print step breaks silently rather than loudly. JSON5.parse reads every number through a JavaScript double, the same as JSON.parse does — good for roughly 15 to 16 reliable digits. Past that, 8901240544102066246 comes back 8901240544102066000 from a plain parse and print. This page reads the original digits from the source text instead, so an ICCID or account number prints exactly as it was typed.

Converting a document

1. Paste the JSON5 – Comments, unquoted keys, single quotes and a trailing comma are all fine on the way in — that is the format this page reads.
2. Read the amber note if one appears – It means the document did not parse at all — fix the JSON5 first, or check it on JSON5 Validator for a location.
3. Copy the strict JSON – Double-quoted keys, double-quoted strings, no trailing commas, no comments — accepted anywhere JSON.parse is.
4. Double-check a long identifier if the file has one – Compare the digits in the output against the source directly — this page prints them exact, but it is a five-second check worth doing on data you did not generate yourself.

If the output needs to keep explaining itself, do not throw the JSON5 version away. Keep the commented JSON5 as the source of truth for humans, and generate the strict JSON from it as a build step whenever something downstream needs it. That is the normal shape of this conversion in a real pipeline — one-way, on purpose.

A JSON5 config, made strict

Unquoted keys, a trailing comma and a comment — none of it valid JSON, all of it disappears or gets rewritten on the way out.

// device config
{
  name: 'edge-gw-04',
  iccid: 8901240544102066246,
  tags: ['edge','gw',],
}

{
  "name": "edge-gw-04",
  "iccid": 8901240544102066246,
  "tags": ["edge", "gw"]
}

When you need this

Feeding a JSON5 config to something that only reads strict JSON

A build step, an HTTP API, or an older library that calls JSON.parse directly all reject unquoted keys and trailing commas outright. Converting once, ahead of time, avoids teaching every consumer to accept the relaxed syntax.

Checking whether a document is actually strict-JSON-compatible

A document can be perfectly valid JSON5 and still fail this conversion if something in it genuinely cannot be strict JSON — though in practice, since every legal JSON5 value has a strict-JSON equivalent, a failure here almost always means the JSON5 itself did not parse. JSON5 Validator confirms that separately with a line and column.

Publishing a config that started life hand-edited

Write and maintain the source as JSON5 — comments explaining each setting, no fighting with trailing commas during edits — then convert to strict JSON for whatever actually ships or gets committed as a generated artifact.

Confirming a long device or account ID is intact

Paste a document holding a fifteen-plus-digit identifier and confirm the JSON output has the same digits as the JSON5 input — the standard precision check, run here instead of trusting it by default.

What this page does

• Runs the real json5 parser, not a regular expression, so unquoted keys, single quotes and trailing commas are all handled per the actual specification.
• Reads long integers from the source text rather than through JSON5.parse's native number handling, so a 19-digit ICCID keeps every digit.
• Refuses outright rather than guessing when the input does not parse — no output that merely looks like valid JSON.
• Runs entirely in your browser, so a config file carrying real credentials or internal hostnames is never sent anywhere.

Questions people actually ask

Why did my comments disappear?

The same reason they disappear from JSON5 Formatter: a comment is not part of the parsed value, so it is gone before this page ever sees the document. Strict JSON has no comment syntax to put it back in even if it survived — json.org's own grammar simply does not include one.

What happens to a trailing comma?

It is dropped, silently and correctly — a trailing comma changes nothing about the value, only about whether the text parses under a stricter grammar. The strict JSON output never has one.

Why does my 19-digit ID look different from a plain json5.parse/JSON.stringify conversion?

Because that plain round trip reads the number through a JavaScript double first, which cannot hold more than about 15 to 16 reliable digits per IEEE-754 double precision — 8901240544102066246 silently becomes 8901240544102066000. This page reads the original digits from the source text specifically to avoid that.

Is the output always valid strict JSON?

Yes — every value JSON5 can represent has a strict-JSON equivalent, so a document that parses as JSON5 always has a valid JSON form. The only failure mode is the input not parsing as JSON5 in the first place.

Related tools

Specifications and references

• JSON5 — a superset of JSON – What is relaxed relative to JSON, defined precisely
• RFC 8259 — The JSON Data Interchange Format – The strict grammar this page's output conforms to
• json5 on npm – The reference implementation this page runs on