JS Object to JSON

Convert JavaScript object literals to valid JSON — handles unquoted keys, single quotes, trailing commas, and comments.

JavaScript Object

or drop a file here

Valid JSONValid

{
  "name": "My App",
  "version": "1.0.0",
  "settings": {
    "debug": true,
    "timeout": 30,
    "hosts": [
      "localhost",
      "127.0.0.1"
    ]
  },
  "tags": [
    "web",
    "api"
  ]
}

How JS Object to JSON conversion works

JavaScript object literals differ from JSON in several ways: keys can be unquoted, strings can use single quotes, trailing commas are allowed, and comments are permitted. This tool reads the input with a real tokenizer rather than pattern-matching over the text, which is what lets it tell a // that starts a comment from one sitting inside a string — { path: 'a//b' } converts correctly instead of being cut off at the slashes. It also accepts hex, binary and octal numbers, NaN, Infinity, undefined, template literals and numeric separators, and it points at the exact line and column when something genuinely will not parse.

Two things are preserved that a naive JSON.parse round-trip destroys. Key order is kept as written — JavaScript objects sort integer-like keys numerically, so { 2: 'b', 1: 'a' } would otherwise come back reordered. And number precision is kept: a literal that is already valid JSON is copied through untouched, so 1.50 stays 1.50 and an ID beyond 2⁵³ does not lose its last digits.

Built and maintained by Meet Shah · Last updated 2 August 2026

What this tool is used for

Converting a JavaScript object literal into valid JSON.
Cleaning up a pasted object with unquoted keys and trailing commas.
Turning a config object from source into a JSON file.
Stripping comments from an object literal to make it parseable.
Producing JSON from an object copied out of a console.

Frequently Asked Questions

What can it convert that JSON.parse cannot?: Unquoted keys, single-quoted strings, trailing commas, and `//` or `/* */` comments — all legal in a JavaScript object literal and all rejected by JSON. Hex, binary and numeric separators such as `1_000` are also understood.
Why does it tokenise instead of using find-and-replace?: Because a whole-document replace has no idea when it is inside a string. A chain of such replacements truncated `{ path: 'a//b' }` at the slashes — reading `//` as a comment — and then reported a syntax error at a position that made no sense.
What happens to a large integer?: It is preserved. An input that is already valid JSON is passed through untouched, so a 19-digit id does not lose its last digits to the float conversion a parse-then-stringify round trip would apply.
Does key order survive?: Yes, including integer-like keys. JavaScript objects sort integer keys numerically ahead of string keys, so a naive round trip silently reorders `{ "10": a, "9": b }` — the tokeniser keeps the source order instead.
What do the line and column in an error mean?: The exact position where parsing stopped, with a caret drawn under it. That is the difference between an actionable error and "unexpected token", which tells you a document is broken but not where.
Are functions and undefined handled?: No — neither has a JSON representation, so an object literal containing them is not convertible. Replace them with a serialisable stand-in, or strip them, before converting.

Common errors and gotchas

Expecting functions, `undefined` or symbols to survive, which JSON has no representation for.
Assuming `NaN` and `Infinity` convert, which JSON does not permit.
Losing a `Date` object's type, which becomes a string with no way back.
Overlooking that JSON requires double quotes, so single-quoted keys must be converted.
Trusting a paste from a console, where the display form is not the literal.