Fix Unquoted Keys in JSON

Object keys like name, active, and profile must be quoted in valid JSON, even when the key looks like a normal identifier.

Why Unquoted Keys Fail

JavaScript allows bare property names in object literals. RFC 8259 JSON does not; every object key must be a double-quoted string. The parser hits the unquoted identifier and rejects it on the spot — usually at position 2, right after the opening {.

Broken Example

{
  name: "Ada",
  active: true,
  profile: { city: "London" }
}

Every key needs quotes — and the rule applies to nested objects too.

Fixed JSON

{
  "name": "Ada",
  "active": true,
  "profile": { "city": "London" }
}

How Different Languages Report It

The error message varies by parser, but the root cause and the fix are identical:

Language / parser Error message
JavaScript (JSON.parse, V8) SyntaxError: Expected property name or '}' in JSON at position 1 (Node 22+) / Unexpected token n in JSON at position 2 (older runtimes)
Python (json.loads) json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)
Go (encoding/json) invalid character 'n' looking for beginning of object key string
jq parse error: Expected separator between values at line 1, column 7

Unquoted keys are part of the broader Unexpected token family — the bare-identifier-at-key-position case routes to this guide.

Why JavaScript Identifiers Look Like JSON Keys

In a JavaScript object literal, { name: "Ada" } is legal because name is a valid identifier (per ECMA-262 §13.2.5). JSON dropped that shortcut so a parser only has to recognize one shape — a quoted string — for every key. The grammar stays small enough to implement in any language: Python's json, Go's encoding/json, and Rust's serde_json can all consume the same payload because there's only one rule for keys.

Keys That Always Need Quotes

Even if a parser accepted bare identifiers, several key shapes would still require quoting in any language. Quoting every key removes all of these edge cases at once:

  • Reserved words like return, class, new, for, if
  • Names containing hyphens like content-type, x-api-key
  • Names containing dots like app.config.debug (the parser would otherwise read it as nested property access)
  • Names starting with a digit like 404, 2fa_enabled
  • Names containing spaces like "first name"
  • Unicode names with combining characters or emoji like "🔑"

When Auto-Repair Can Safely Quote Bare Keys

The JSON Fix tool quotes bare identifiers that appear in a key position — directly after { or , and followed by :. It does not touch already-quoted keys, values, or text inside strings, so adding quotes is safe even when the document mixes valid and invalid keys. Single-quoted keys are converted to double-quoted; already-correct keys are left alone. After auto-repair, run the result through the strict JSON validator to confirm.

JSON5 and JSONC

JSON5 and JSONC (the format VS Code uses for tsconfig.json and settings.json) both allow unquoted keys and comments. They are fine for human-edited configuration but not interchange — never expose JSON5 over an API or send it across a process boundary, since standard JSON clients will reject it.

Related JSON Syntax Errors

Unquoted-keys JSON often arrives alongside other JavaScript-style sins: single-quoted strings, trailing commas, line comments, or undefined values. The repair workflow hub walks through the full sequence.

FAQ

Why does my JSON have unquoted keys?

Usually because it was copy-pasted from a JavaScript object literal, or generated by a templating engine that emitted the keys without quotes, or output by console.log(obj) in Node and saved as-is. LLM responses also sometimes drop the key quotes when the model is asked for "JSON-like" data without strict instructions.

Can I leave keys unquoted in package.json?

No — package.json is strict RFC 8259 JSON, parsed by npm, yarn, pnpm, and every package-resolution tool. Only the JSONC files in your editor (tsconfig.json, .vscode/settings.json) tolerate it.

Why does the parser say the error is at position 1 or 2 — the unquoted key starts later?

The parser is reporting where it expected something different (usually a "), not where the actual identifier begins. After the { it expects either } (empty object) or " (start of the first key); finding anything else, it stops immediately.

See also

This guide is one stop in a larger repair workflow that covers trailing commas, unquoted keys, single quotes, and stringified-object errors. Open the hub for the full sequence.

Sources

  • RFC 8259 — the JSON Data Interchange Format (IETF, the canonical JSON grammar)
  • ECMA-404 — the JSON Data Interchange Syntax
  • MDN — JSON.parse (the strict parser that emits this error in JavaScript)
  • MDN — Object initializer (the JavaScript syntax that does allow bare keys, per ECMA-262 §13.2.5)
  • JSON5 — the human-edit-friendly superset that allows unquoted keys

Last reviewed June 2026.