Six reasons your JSON fails to parse

JSON has no tolerance built into it. It permits no comments, requires double quotes for every string and every key, and forbids a comma after the final element. That strictness is deliberate — it makes the format unambiguous and trivially parseable — but it also means configuration files and API payloads fail for reasons that are genuinely hard to see.

The six mistakes, in order of frequency

A trailing comma. {"a": 1, "b": 2,} is invalid. JavaScript objects tolerate it; JSON does not. It is the single most common cause of a parse failure, and it is invisible unless you are looking for it.
Single quotes. {'name': 'value'} is not JSON. Every string, including every key, must use double quotes. This usually arrives by copying from Python or from hand-written JavaScript.
Unquoted keys. {name: "value"} works in JavaScript and fails in JSON. Keys are always strings.
Comments. Neither // nor /* */ exists in the specification. Every annotation has to go — many editors and toolchains use a relaxed superset such as JSON5 or JSONC, which is why the file may work in one place and fail in another.
Invisible characters. A byte-order mark at the start of the file, a non-breaking space where a normal space should be, or a zero-width character picked up by copying and pasting out of a document or a chat window.
Unescaped backslashes. On Windows, "C:\Users\me" is invalid because \U is not a legal escape. It must be written "C:\\Users\\me" — or as a forward slash, which works everywhere.

Find the position, not just the failure

Nearly every parser will tell you where it gave up, but the raw message — Unexpected token } in JSON at position 482 — is expressed as a character offset, which is not something you can navigate to.

Paste the document into the JSON formatter. It converts that offset into a line and column and reports it alongside the parser's own message, so you can go straight to the spot. In practice the real error is often on the line before the reported position: a missing comma is only discovered when the parser reaches the next token.

A reliable procedure for a file that will not parse

Paste it in and read the reported line and column.
Check that line and the one before it for the first four mistakes above.
If the text looks correct, inspect the raw bytes around the position — invisible characters do not show in an editor.
If the file was assembled from several sources, suspect the seams first. A missing comma between two concatenated objects is a classic.
Once it parses, use Format to lay it out with proper indentation. It is far easier to proofread a structure you can see.

Escaping, and why it confuses people

Two separate operations get called "escaping", and mixing them up wastes a lot of time.

Escaping turns a piece of text into a JSON string literal — {"a":1} becomes "{\"a\":1}". You need this when a JSON document has to be embedded inside another JSON document, or stored in a string column.
Unescaping reverses it, recovering the original text.

If you have a field containing escaped JSON and you double-escape it, the result parses but contains the wrong data — a bug that surfaces much later and much further away. The formatter offers both directions as separate buttons precisely so you can tell which one you need.

If the JSON is enormous

Browsers handle text areas comfortably up to about 10 MB. Beyond that, paste a representative fragment to find the structural problem, then fix the full file in an editor. Command-line tools such as jq are better suited to documents measured in hundreds of megabytes, and will report positions too.