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.
JSON repair guides
Topic hubs
- JSON Parse Errors: Read the Message, Jump to the Fix
- Fix Invalid JSON: From 'What's Wrong' to a Clean File
- JSON Formatter, Validator, Viewer: Pick the Right Tool
- Repair LLM JSON Output: Handling Almost-JSON from AI
- Privacy: JSON Tools That Don't Leave Your Browser
- JSON Interop: YAML, CSV, XML, JWT, Schema
Specific guides
- How to Decode Base64 Strings (and JWT Payloads)
- URL Encoding: Percent-Encode Query Parameters and Paths
- Convert YAML to JSON (and Avoid Indentation Errors)
- Convert JSON to CSV: Flatten an Array of Objects
- Convert JSON to XML: Root Elements, Attributes, and Arrays
- Escape JSON as a String Literal (and Decode Double-Encoded JSON)
- Fix Trailing Comma in JSON
- Fix Single Quotes in JSON
- Repair LLM JSON Output
- Fix JSON Parse Error: Expected Property Name
- JSON vs JS Object Literal: The Key Differences
- Validate JSON Before API Requests
- JSON Formatter vs JSON Repair
- Fix JSON Unexpected Token Errors
- JSON to JavaScript Object Converter