Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool

JSON Quoting Styles and Formatting Preferences

If you only need the short answer, here it is: standard JSON always uses double quotes for object keys and string values. Single quotes, comments, and trailing commas may look familiar from JavaScript, but they make the data invalid for normal JSON parsers.

The formatting part is more flexible. Indentation, line breaks, and key ordering are style choices, not JSON syntax rules. The best preference is the one your team can apply automatically and consistently.

Quick Guidance

Use double quotes everywhere JSON expects a name or string.
Escape inner double quotes with \" and backslashes with \\.
Do not use comments, trailing commas, or bare identifiers in standard JSON.
Prefer 2-space indentation unless an existing project already uses 4 spaces or tabs.
Use JSON5 only when your exact parser or toolchain explicitly supports it.

What Standard JSON Actually Requires

In standard JSON, an object member name is a string, and strings are written with double quotes. That means both the key and any text value must use "...", not '...'.

Valid JSON

{
  "name": "Alice",
  "role": "Editor",
  "active": true,
  "tags": ["json", "formatting"]
}

Numbers, booleans, arrays, objects, and null are not quoted unless they are meant to be strings. For example, "30" and 30 are different values.

Why Single Quotes Break JSON

Many developers run into this after copying a JavaScript object literal, a config snippet, or an API example that is not actually JSON. A normal JSON parser rejects single-quoted strings and keys.

Invalid JSON

{
  'name': 'Bob',
  "city": "London",
  "enabled": true,
}

This fails for two separate reasons: single quotes are not valid JSON string delimiters, and the trailing comma after true is not allowed in standard JSON.

JSON vs JavaScript Object Literals vs JSON5

Searchers often ask about JSON quoting styles when they are really comparing three different syntaxes. They look similar, but they are not interchangeable.

Format	Quotes	Comments / Trailing Commas	Best Use
Standard JSON	Double quotes required for keys and strings	Not allowed	APIs, data exchange, storage, interoperability
JavaScript Object Literal	More permissive, depending on JavaScript syntax	Allowed in many cases	Source code, not cross-language data interchange
JSON5	Single quotes and unquoted keys may be allowed	Allowed	Human-edited config files when tooling explicitly supports JSON5

The practical rule is simple: if another system, API, validator, or parser expects JSON, assume it means strict JSON unless the documentation clearly says otherwise.

How to Quote and Escape Strings Correctly

Double quotes are required around every JSON string, but double quotes can still appear inside the value as long as they are escaped. The same applies to backslashes and control characters such as newlines and tabs.

Escaping Example

{
  "message": "She said, \"Ship it.\"",
  "path": "C:\\Users\\alex\\Downloads",
  "note": "Line one\nLine two"
}

A common mistake is pasting text that already contains raw quotes or Windows-style paths and forgetting to escape them. A formatter can re-indent valid JSON, but it cannot guess your intent if the string itself is malformed.

Recommended Formatting Preferences

JSON has only a few hard syntax rules. Most formatting preferences are about readability, review quality, and stable diffs in version control.

Indent with 2 spaces by default. It is compact, widely understood, and works well for nested data. Use a different width only when a project already has an established convention.
Put a space after each colon. "name": "Alice" is much easier to scan than "name":"Alice".
Break nested objects and long arrays across lines. Inline JSON is fine for tiny payloads, but multi-line formatting is easier to review and debug.
Treat key order as a style choice, not a semantic guarantee. Some teams sort keys for stable diffs, but consumers should not rely on object member order unless the application defines that behavior separately.
Apply the style automatically. A formatter is better than manual alignment, especially when multiple people edit the same file.

When JSON5 Is Fine and When It Is a Bad Idea

JSON5 can be a good fit for local configuration files that humans edit by hand. Comments, trailing commas, and less strict quoting make those files more pleasant to maintain.

It is usually the wrong choice for APIs, exported data, third-party integrations, browser JSON.parse, or anything that needs maximum compatibility. If you are sending data across systems, convert it to strict JSON before it leaves your app or build step.

Common Validation Failures

Unexpected token ': You used single quotes around a key or string.
Unexpected token /: A comment was pasted into standard JSON.
Unexpected token ] or }: A trailing comma is present before the closing bracket or brace.
Bad control character in string literal: A newline, tab, or backslash inside a string was not escaped correctly.

Best Working Preference for Most Teams

If you need a default policy, this one is hard to regret: strict JSON, double quotes only, UTF-8 text, 2-space indentation, one formatter, and no hand-written style exceptions. It is compatible with essentially every JSON parser and keeps diffs readable.

If your input does not parse, fix validity first, then format it. A formatter helps with layout. It does not make invalid JSON valid unless the tool explicitly performs a cleanup or conversion step.

Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool