JSON Unquoted Keys SyntaxError — Why It Happens and How to Fix It

The JSON specification in RFC 8259 defines the grammar for a JSON object precisely: an object is a pair of curly braces surrounding a comma-separated list of members, where each member is a string followed by a colon followed by a value. The definition of member begins with string — not identifier, not name, not token — and the definition of string requires it to begin and end with a double-quote character. There is no provision in the grammar for unquoted keys, and there never has been.

This stands in contrast to JavaScript's object literal syntax, which allows both unquoted identifiers and quoted strings as property names. In JavaScript, { name: 'Alice' } and { "name": "Alice" } are equivalent and both create an object with a single property. The ECMAScript specification explicitly permits identifier names as property names in object literals, which is why unquoted keys feel natural to JavaScript developers.

JSON was designed to be a language-independent data interchange format, not a subset of JavaScript. Although it was originally derived from JavaScript object literal notation and the name JSON stands for JavaScript Object Notation, the designers made a deliberate simplification by requiring keys to be strings. This means any language with a string type can parse JSON keys without understanding JavaScript's identifier lexer. Requiring double quotes also eliminates ambiguity about which identifiers are valid keys — in JavaScript, reserved words like class, for, and delete are allowed as unquoted keys in modern syntax but forbidden in older ECMAScript versions. By requiring quotes, JSON sidesteps all of this complexity.

The error message varies by JavaScript engine. V8 (Node.js and Chrome) typically says 'Unexpected token n in JSON at position 1' when the input is { name: 'Alice' } — the 'n' at position 1 is the first character of the unquoted key 'name', which is not a valid JSON token at that position. Firefox says 'JSON.parse: expected property name or '}' at line 1 column 2'. Both messages are telling you the same thing: the parser expected a string delimiter (a double-quote) and instead found the start of an unquoted identifier.

When JSON.parse throws about an unexpected token at position 1 or 2, the most common cause is an unquoted key at the very beginning of the object. Position 1 in { name: 'Alice' } is the 'n' character, which comes immediately after the opening brace and the space. A correctly formatted JSON object would have a double-quote character at that position: { "name": "Alice" }.

For larger payloads, the error position may point to a nested object rather than the root. The JSON parser reads correctly until it encounters the first unquoted key and throws at that character's position. Count from position 0 to find the relevant section of the JSON text, or paste the payload into a validator that highlights the error line. Most validators highlight the specific token that caused the parse failure, making it visually obvious whether the issue is a missing quote, a trailing comma, or a different problem entirely.

A useful diagnostic technique is to run the text through a JSON5 parser, which accepts unquoted keys. If JSON5 parses it successfully and produces a sensible object, the input is valid JSON5 with unquoted keys. If even JSON5 fails, the input has deeper structural problems. This comparison tells you whether you need to add quotes or whether more significant repair is needed.

For machine-generated JSON that has this issue, trace the generation path back to the code that writes the output. The fix is almost always to replace manual string building or JavaScript template literals with a call to JSON.stringify. In Python, the equivalent fix is to replace manual dict-to-string conversion with json.dumps. Once the generator uses a proper serializer, every future output will have correctly quoted keys without any manual intervention.

For a JavaScript object defined in source code, the simplest transformation is JSON.stringify(myObject, null, 2). This serializes the object with two-space indentation and produces fully spec-compliant JSON with double-quoted keys and double-quoted string values. The null second argument means no replacer is used, so all values are serialized as-is. This one-line fix works in Node.js, browsers, and any JavaScript environment.

For hand-written JSON files that need to be corrected — where you have text with unquoted keys and need to produce valid JSON — a regex-based transformation works for simple cases. The pattern /([{,]\s*)(\w+)(\s*:)/g matches an unquoted key (a word character sequence) preceded by either an opening brace or a comma and followed by a colon, and replaces it with the same key wrapped in double quotes. In JavaScript: jsonText.replace(/([{,]\s*)(\w+)(\s*:)/g, '$1"$2"$3'). This quick fix works for simple keys composed of letters, digits, and underscores, but it fails for keys containing hyphens, spaces, or special characters.

For Python code that serializes dictionaries, replace any string concatenation or f-string JSON generation with import json and json.dumps(myDict, indent=2). Python's json module is part of the standard library, handles all escaping and quoting correctly, and works identically to JSON.stringify from a compliance perspective. The key difference is that Python's True and False become JSON's true and false, and Python's None becomes JSON's null, which json.dumps handles automatically.

For API testing tools like Postman, Insomnia, or cURL, paste JSON into the body field rather than JavaScript object notation. If the tool has a 'JSON' body type selector, use it — some tools auto-add the Content-Type header and may attempt to validate the body as JSON before sending. Writing the body as valid JSON from the start prevents parsing errors on both the client tool side and the server side.

JSON5 is a superset of JSON that extends the format with several JavaScript-inspired features: unquoted keys that are valid ECMAScript 5 identifiers, single-quoted strings, trailing commas in arrays and objects, and single-line and multi-line comments. It was created specifically for human-written configuration files where the strictness of JSON is a usability obstacle. JSON5 is available as an npm package (json5), and several popular tools use it for their configuration files.

The critical distinction is that JSON5 is not interoperable with standard JSON parsers. If you write a .json5 file and pass it to any code that calls JSON.parse, parsing will fail on the first unquoted key. JSON5 requires its own parser. Some projects use .jsonc files (JSON with comments) or .json5 files with specific tooling support, but when the file extension is .json, the parser is almost always the standard JSON.parse with no tolerance for unquoted keys.

Popular tools that accept JSON5 or JSON-with-comments include VS Code's settings.json, TypeScript's tsconfig.json, and Prettier's configuration files. These tools use their own parsers that extend standard JSON parsing. When you copy configuration from these files and use it as a JSON payload in an API call or pass it to JSON.parse directly, it fails because those extensions are not standard JSON.

The practical rule is: if humans are writing or reading the file and it does not need to be consumed by a general-purpose JSON parser, JSON5 or JSONC is a better format than standard JSON. If the file is consumed by application code, API endpoints, or configuration loaders that use JSON.parse, use standard JSON with double-quoted keys. Keep both use cases clearly separated in your project structure and document which format each configuration file uses.

The regex approach for adding quotes to unquoted keys — replacing word characters before a colon with quoted versions — has a significant limitation: it only handles keys that consist entirely of word characters (letters, digits, and underscores). Keys that contain hyphens, like content-type, max-age, or my-config-key, are not matched by \w+ because the hyphen is not a word character.

In JavaScript object literal syntax, a hyphenated key requires quotes even in a JavaScript object: { 'content-type': 'application/json' } — you cannot write { content-type: 'application/json' } because the hyphen would be interpreted as a subtraction operator. So if the input is valid JavaScript, hyphenated keys are already quoted and the regex handles them correctly (it does not need to match them because they already have quotes). But if the input was generated by a tool that uses hyphens in unquoted keys — which is possible in some serialization systems — the regex will fail silently by not quoting those keys.

The regex also fails for keys that start with a digit (like 0foo) or contain unicode letters that are not ASCII. These are edge cases in practice but important to know about when using regex-based transformation. A production-grade transformation should use a proper parser — either a JSON5 parser that can read the input, or a custom tokenizer that handles all valid JavaScript identifier forms.

Another common mistake is applying the regex to the entire JSON text, including string values that happen to contain patterns that look like unquoted keys. For example, a string value that contains the substring name: would be incorrectly modified by the regex. A correct transformation must understand the JSON structure — specifically, it must only apply the key-quoting transformation to the member portion of an object, not to string values. This is difficult to do correctly with a simple regex and is another reason why using a parser is the right approach for any non-trivial transformation.

The cheapest way to prevent unquoted key errors is to catch them during development rather than at runtime. Several tools integrate JSON validation into the development workflow and report errors at the file level before code is run.

ESLint with the eslint-plugin-json or eslint-plugin-jsonc plugin validates JSON files as part of the normal lint pass. Configure it to run on all .json files in the project. When a developer saves a JSON file with unquoted keys, the linter reports the error in the editor immediately rather than waiting for a runtime failure. The plugin integrates with most editors through the ESLint extension, providing inline error highlighting.

VS Code's built-in JSON language server validates .json files against the JSON grammar and highlights syntax errors including unquoted keys in real time. The distinction between .json (strict JSON) and .jsonc (JSON with comments) files controls which rules apply — .json files are validated strictly, while .jsonc files allow comments. Consistently using .json for files that must be parsed by JSON.parse and .jsonc or .json5 for human-written configs prevents the format confusion that leads to this error.

For CI pipelines, add a JSON validation step that runs python -m json.tool on all JSON files or uses jq . to test parsing. A command like find . -name '*.json' -not -path './node_modules/*' | xargs -I{} python -m json.tool {} will fail the CI build if any JSON file in the project has a syntax error, including unquoted keys. This check is fast, requires no additional dependencies beyond Python, and runs in seconds even for projects with hundreds of JSON files.

For teams migrating from JavaScript object notation to JSON in configuration files, a one-time transformation script is more reliable than manual editing. Write a Node.js script that requires or evaluates each JavaScript config file, then calls JSON.stringify to produce a correct JSON version, and writes the result to a new file with the .json extension. This approach handles all edge cases automatically — hyphenated keys that were already quoted, number keys, nested objects — because JSON.stringify processes the runtime object rather than the source text.