SyntaxError: Single Quotes Are Not Valid in JSON

The formal grammar of JSON is defined in RFC 8259, published by the Internet Engineering Task Force. The grammar rule for a JSON string is explicit: a string begins with a quotation mark character, which is Unicode code point U+0022, followed by any sequence of valid characters, followed by another quotation mark. The character U+0022 is the ASCII double quote. There is no provision in the grammar for single quotes, curly apostrophes, backtick characters, or any other delimiter. The RFC treats these as invalid characters at the start of a string value, which causes the parser to raise a syntax error immediately upon encountering them.

This strictness is intentional. JSON was designed to be simple enough that any programmer could implement a correct parser in an afternoon, and to be unambiguous enough that two different implementations would always produce identical results when parsing the same input. Allowing single quotes as an alternative string delimiter would complicate the grammar and introduce edge cases around strings that contain both single and double quotes, or strings where one type of quote is used as an apostrophe.

The confusion most often arises because JavaScript, the language that inspired JSON's syntax, allows single quotes, double quotes, and backticks as string delimiters in object literals. A JavaScript object literal is source code, subject to the JavaScript parser's rules. A JSON document is a data interchange format, subject to RFC 8259's rules. These two contexts look similar on screen but are parsed by entirely different mechanisms with entirely different rules.

Python adds a further layer of confusion because Python's default string representation for dictionaries uses single quotes. When a Python developer prints a dictionary or calls repr() on one, the output uses single-quoted strings even for values that do not contain any quote characters. This output looks almost identical to JSON and will pass a casual visual inspection, but it fails any standards-compliant JSON parser. Python's own json module handles this correctly because json.dumps always produces double-quoted output, but developers sometimes bypass the json module by using str() or repr() for quick debugging and then accidentally treat that output as JSON.

A third source of single-quoted JSON is manual construction using shell scripts or string concatenation. Shell scripting often uses single quotes to avoid variable expansion, and a script that builds a JSON string by concatenating shell variables will naturally produce single-quoted output if the author is not careful about the quoting context. The correct approach in shell scripts is to use a JSON-generation tool like jq or to use a proper programming language for JSON construction rather than raw string manipulation.

The error message from a JSON parser points directly to the problem: the position in the string where the unexpected character was encountered. For single-quote errors, the position is typically zero or close to the beginning of the string, because the very first key in a JSON object is usually a string that begins with a quote character. If the parser sees a single quote where it expected a double quote, it reports the error at that position.

To find the source of the single-quoted JSON, trace backward from where the parsing error occurs. If the JSON came from a network request, log the raw request body before parsing. If it came from a file, open the file in a hex editor or a text editor with visible character mode to confirm what quote characters are actually present. Visually, single quotes and double quotes are similar in many monospace fonts, particularly at small sizes, so confirming by character code rather than visual inspection is more reliable.

If the JSON came from Python code in another part of the system, look for any code that calls str(), repr(), or print() on a dictionary or object and then passes the result to another function expecting JSON. Any use of these methods to serialize data rather than json.dumps is a potential source of single-quoted strings. A static code analysis pass looking for calls to json.loads or json.parse that receive the output of str() or repr() will surface these patterns quickly in a large codebase.

For JSON that comes from external APIs or third-party services, the issue is harder to fix at the source. In this case, the receiving end must either preprocess the input to replace single quotes with double quotes before parsing, or use a more lenient parser that accepts non-standard JSON. Both approaches carry risks: preprocessing with simple string replacement can corrupt strings that contain apostrophes or intentional single quotes, and lenient parsers may accept other non-standard constructs that later cause issues when the data is re-serialized to strict JSON. The cleanest long-term solution is to contact the API provider and request that they fix their output to comply with RFC 8259.

The safest and most reliable fix in every language is to use the official JSON serialization library rather than relying on language-specific string representations. In Python, this means replacing any use of str(data) or repr(data) with json.dumps(data). The json.dumps function handles all the necessary transformations: it converts Python's True and False to JSON's lowercase true and false, converts Python's None to JSON's null, and uses double quotes for all string values. For more complex objects, the default parameter allows customizing how non-serializable types are converted.

In JavaScript, replacing manually constructed JSON strings with JSON.stringify ensures correct output. JSON.stringify handles escaping of special characters within strings, converts dates, and produces valid JSON regardless of what the original JavaScript string delimiters were. If a JavaScript object was written using single-quoted string values and then converted to a JSON string, JSON.stringify will produce properly double-quoted JSON output because it operates on the parsed values, not on the source code syntax.

When you receive single-quoted JSON from an external source that cannot be fixed, a preprocessing step is necessary. A naive approach is to call replace("'", '"') on the raw string, but this breaks strings that contain apostrophes. The word it's, for example, would become it"s after a blind replacement, producing invalid JSON. A slightly better approach is to use a regular expression that replaces single quotes only when they appear at the start or end of a value position, but these patterns quickly become complex enough to fail on edge cases.

The most robust preprocessing approach for Python-repr-style input is to use Python's ast.literal_eval function, which safely evaluates a string containing a Python literal expression and returns the corresponding Python object. Since Python's repr output is a valid Python literal, ast.literal_eval can parse it correctly, including handling apostrophes and escaped characters correctly. The result is a Python dict that can then be serialized with json.dumps to produce valid JSON. This approach is safe because ast.literal_eval does not execute arbitrary code and raises ValueError for any input that is not a recognized Python literal.

For shell scripts, the canonical fix is to use jq for JSON construction. The jq command-line tool can build JSON from shell variables using --arg and --argjson parameters, which handle quoting and escaping automatically. Alternatively, using Python as a one-liner to construct JSON from shell variables is reliable and avoids the quoting complexities of shell-native JSON construction.

JSON5 is a separate data format, not a version of JSON, that extends the JSON syntax to include several conveniences from JavaScript's ES5 object literal syntax. Among the extensions JSON5 supports is the use of single quotes as string delimiters. JSON5 also supports trailing commas in objects and arrays, unquoted keys that are valid JavaScript identifiers, comments, and multi-line strings. If the data you are working with uses single quotes along with these other extensions, it may be intentionally formatted as JSON5 rather than JSON.

The distinction matters because a JSON5 file should not be parsed with a JSON parser, and a JSON file should not need a JSON5 parser to be read correctly. If you are consuming JSON5 from a configuration file or a data source that uses the .json5 file extension, use a JSON5 parsing library rather than trying to preprocess the input to remove single quotes. Libraries like json5 in Node.js and json5 in Python handle the full JSON5 grammar correctly.

JSON5 is popular in configuration files, particularly in JavaScript projects where configuration authors are more comfortable with JavaScript syntax than strict JSON. Babel configuration files use JSON5, and some tools like ESLint configuration files accept JSON5 syntax. However, it is important not to use JSON5 in API response bodies or anywhere that the consumer is expected to use a standard JSON parser, because most JSON parsers do not accept JSON5 syntax.

If you are building a tool that accepts configuration files, consider whether your users would benefit from JSON5's leniency. Allowing single quotes, trailing commas, and comments in configuration files significantly reduces the friction of hand-editing configuration. Just be explicit in your documentation about whether the format is JSON or JSON5, and use the appropriate parser accordingly. Mixing JSON and JSON5 in the same project without clear labeling is a common source of confusion.

JSONC, which stands for JSON with Comments, is another variant that allows C-style comments inside JSON documents but still requires double quotes for strings. JSONC is used by TypeScript's tsconfig.json and VS Code's settings.json. If your tool uses JSONC, single quotes are still not valid, and the only extension over standard JSON is the permission to use line comments and block comments.

The most tempting quick fix for a single-quote JSON error is to replace every single quote in the string with a double quote. This approach seems obvious and works for simple cases where the JSON values contain no apostrophes. For real-world data, it almost always produces incorrect output because natural language text frequently contains apostrophes in contractions and possessives.

Consider a JSON-like string with the value 'The user\'s profile data'. After blind replacement of single quotes with double quotes, this becomes "The user"s profile data", which breaks the JSON structure because the double quote after user terminates the string prematurely. The remainder of the string, s profile data, appears outside the string value and causes a parse error.

A second trap is assuming that the single-quote problem is limited to the outermost string delimiters. Python's repr output sometimes escapes internal single quotes with a backslash, as in 'The user\'s data'. When you replace the outer single quotes with double quotes, the internal escaped single quote becomes \' which is not a valid JSON escape sequence. JSON's string escape sequences are specific: backslash followed by one of double quote, backslash, forward slash, b, f, n, r, t, or a u followed by four hex digits. A backslash followed by a single quote is not a valid JSON escape and will cause a parse error.

A related mistake is using a regular expression replacement that looks for quoted strings in the Python-repr format. These regular expressions tend to fail on edge cases involving strings that contain the delimiter character, strings with backslash sequences, or strings that span multiple lines in Python's repr output. Regular expression parsing of quoted strings is a known hard problem in computer science, and any regex-based approach will have blind spots for adversarial or simply unusual inputs.

The reliable way to avoid the apostrophe trap is to use a proper language parser to interpret the source format, not a text manipulation tool. Python's ast.literal_eval parses Python repr output correctly regardless of apostrophes or escape sequences. For JavaScript object literals, a full JavaScript parser like Babel or acorn can parse the object and then JSON.stringify can re-serialize it correctly. These tools understand the escaping rules of the source format and handle all edge cases that string replacement misses.

Preventing single-quote JSON errors is significantly easier than debugging them after they reach production. A combination of linting, schema validation, and serialization discipline can eliminate this class of error from a project entirely.

For JavaScript and TypeScript projects, configuring Prettier with the singleQuote option set to false ensures that all code files use double quotes. While this affects JavaScript code rather than JSON data files, it creates a consistent mental model where developers expect double quotes in both contexts. ESLint's quotes rule can enforce the same convention for files that are not processed by Prettier. For JSON data files specifically, the jsonc-eslint-parser and eslint-plugin-jsonc plugins can lint JSON files with ESLint rules, catching syntax errors and style issues before they reach a parser.

For API endpoint testing, including a step that parses every API response body through a strict JSON parser before examining the content will catch single-quote errors and other malformed JSON before they reach the business logic layer. In an Express.js or Fastify application, middleware that calls JSON.parse on the raw request body and returns 400 Bad Request for any parse error prevents single-quoted JSON from propagating into the application. Most frameworks apply this parsing automatically when the Content-Type is application/json, but adding explicit error handling for the parse step makes the failure mode visible rather than silently swallowing malformed input.

For data pipelines that receive input from multiple sources including Python services, establish a contract at the boundary where data enters the pipeline: all JSON must be validated by a JSON Schema validator before processing. A validator like ajv in Node.js or jsonschema in Python will reject any input that is not well-formed JSON, including single-quoted strings. Combining schema validation with schema-defined types means that the error message describes not just that the JSON is malformed but also which field and which type constraint failed, making debugging faster.

For configuration files that are edited by hand, choosing a format that is more forgiving than strict JSON reduces the operational burden without sacrificing correctness. TOML is strongly typed, human-readable, and does not require quotes around most string values. YAML allows both single and double quoted strings. JSON5 allows single quotes. Any of these formats can be compiled to JSON for consumption by tools that require it, with the compilation step serving as a validation checkpoint that catches quoting errors at build time rather than at runtime.