JSON to JSON5

Going the other way: from generated to editable

Plenty of JSON gets produced by a tool — an export, an API response, a build artifact — and then someone has to turn it into a config file a person will maintain by hand. That is what this direction is for. It runs the same real json5 library as JSON5 to JSON, just calling its writer instead of its reader: object keys that are valid identifiers come out unquoted, strings prefer single quotes, and the final item in an object or array gets a trailing comma — the exact JSON5 conventions defined in the specification.

One thing this cannot do is invent comments. RFC 8259's grammar has nowhere to carry an explanation of why a value is what it is, so there is nothing here to convert — that has to be written by hand once the file is in JSON5 form. What this page buys you is the syntax that makes adding those comments possible in the first place, which strict JSON never allows at all.

Long integers are read from the JSON source text directly rather than through a plain JSON.parse, so an ICCID or account number with more digits than a JavaScript number can hold comes out exactly as it went in — the same handling used throughout this site's JSON tools.

Converting a document

1. Paste the JSON – Any valid JSON document — object or array at the top level.
2. Copy the JSON5 – Unquoted keys where possible, single-quoted strings, a trailing comma on the last item of each object and array.
3. Add the comments by hand – This is the point of converting — open the output in an editor and annotate the values a future reader will need explained.
4. Check a long identifier carried over exactly – Compare the digits against the source if the document has an account or device ID over fifteen digits — worth thirty seconds on data you did not generate yourself.

A key that is not a valid JavaScript identifier stays quoted — a key with a space, a hyphen, or one starting with a digit cannot be written unquoted in JSON5 any more than it could be an unquoted JavaScript object key. That is not a bug in the output; it is the same rule JSON5 Validator checks on the way back in.

Strict JSON, made editable

The mirror of the example on JSON5 to JSON — same data, produced the other direction, ready for someone to annotate.

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

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

When you need this

Turning a generated config into a maintained one

An exported settings file or a scaffolding tool's output often needs someone to actually live in it afterward. Converting to JSON5 first is what makes leaving comments for the next person possible.

Preparing a template for hand-editing

A base config pulled from an API or a database export becomes the starting point for a file a developer will tweak repeatedly — JSON5's trailing commas alone save a class of edit-time syntax errors.

Matching a project's existing JSON5 style

A codebase that already uses JSON5 for its own config files (a Babel or webpack setup, for instance) reads more consistently when new files match — this saves retyping quoted keys as unquoted ones by hand.

Round-tripping to check nothing changed

Paste the output back into JSON5 to JSON and confirm you get the original document — a five-second check that the conversion did not alter any value.

What this page does

• Writes JSON5 through the real json5 library, so the unquoted-key and quoting rules match the specification exactly rather than a hand-rolled approximation.
• Reads long integers from the JSON source text, so a 19-digit ICCID or account number is not silently rounded before it is rewritten.
• Leaves a trailing comma on the last item of every object and array — legal JSON5, and the syntax detail that saves the most edit-time errors in a hand-maintained file.
• Runs entirely in your browser, so nothing you paste — including a config carrying real credentials — is sent anywhere.

Questions people actually ask

Why are some of my keys still quoted?

Because JSON5 unquoted keys have to be valid JavaScript identifiers — no spaces, no leading digit, none of a short list of reserved characters. A key like "api-key" or "2fa_enabled" stays quoted because writing it unquoted would not be valid JSON5 at all, the same rule JSON5 Validator would reject it under if you tried.

Can this add comments explaining my data automatically?

No — a comment explains intent, and intent is not something a JSON document carries. What this page does is produce syntax that CAN hold comments, so you can add them yourself once the file is in JSON5 form. Nothing about the conversion can infer what you would want said.

Why single quotes instead of double quotes for strings?

That is json5's own writer default, and it matches common JSON5 style — double quotes only get used when a string itself contains a single quote, avoiding an escape. See the json5 package for its full stringify behaviour.

Will strict JSON tools still accept this output?

No, and that is the point of converting — JSON5's unquoted keys and trailing commas are exactly what a strict JSON parser rejects. If you need output both tools can read, keep the original JSON and use this only for the version a person will edit by hand.

Related tools

Specifications and references

• JSON5 — a superset of JSON – What the writer targets, and why each relaxation exists
• MDN — Identifier – The rule deciding which keys stay quoted
• json5 on npm – The reference implementation this page runs on