JSON vs JavaScript objects

By Bruno J F Costa · Why something that “runs in the console” still fails every other parser.

Developers meet JSON through JavaScript first. That is useful and also the source of most confusion. A JavaScript object literal and a JSON text look similar. They are not the same language. JSON is a data interchange format defined by RFC 8259. JavaScript is a programming language that happens to have inspired JSON’s syntax. If you copy a value from a .js file into a Python, Go, Java, or JSON.parse call, the extra JS conveniences become syntax errors.

This page is about that gap. The errors guide lists symptoms. Here we explain the model so you stop treating the two as interchangeable.

What JSON actually is

A JSON text is one value: an object, array, string, number, true, false, or null. Objects are unordered collections of name/value pairs. Names are strings in double quotes. There is no comment syntax, no trailing comma after the last member, no hexadecimal numbers, and no identifier names without quotes.

The point of that strictness is portability. A PHP service, a mobile client, and a warehouse job should parse the same bytes. If the document only works in one forgiving JavaScript engine, it is not interchange JSON — it is a JS snippet.

What a JavaScript object may contain

In source code you can write:

const user = {
  name: 'Ada',      // unquoted key, single quotes
  score: undefined, // not a JSON token
  extra: NaN,       // not a JSON number
}

That is valid JavaScript. JSON.stringify(user) will drop undefined keys and turn NaN into null. The original source, pasted into a formatter, will not parse. That distinction — “the runtime object” versus “the text I copied” — is where people lose an hour.

undefined is not null

JSON has null. It does not have undefined. In JavaScript, undefined often means “this property was never set.” In JSON you must choose: omit the property, or send null if the API treats null as an explicit empty. Those are different contracts. Silently replacing one with the other can hide bugs (a missing field versus a field present and empty).

When you convert, decide per field. Do not hope the next language’s JSON library will invent undefined for you.

Comments and trailing commas

JavaScript allows // and /* */. JSON does not. Editor formats such as JSONC (VS Code settings) and JSON5 are supersets. They are fine inside a project that documents the parser. They are not fine in an HTTP body that a Go service will json.Unmarshal.

Trailing commas after the last property are the same story: convenient in JS and TypeScript, illegal in RFC 8259. Relaxed mode on JSON Quiet can strip those commas while you clean a paste. Ship only what passes strict validation.

How to convert without guessing

If you have a live JS value, prefer JSON.stringify(value, null, 2) in a scratchpad you control — not a screenshot of the source.
If you only have source text, paste it into JSON Quiet and Validate. Fix the first error (usually a quote or comma). Repeat.
Replace undefined with an omitted key or null after you know the API’s rule.
Remove comments or move them to a README. Do not leave them “for later.”
Validate again in strict RFC 8259 before the payload leaves your machine.

Functions, dates, and class instances

JSON cannot represent functions, Symbol, or a real Date object. JSON.stringify turns dates into ISO strings and drops functions. That is expected. If your domain needs richer types, define a convention (ISO-8601 strings, integer epoch milliseconds) and document it. Do not expect a generic formatter to revive a class instance.

Convert a paste in the formatter →