You copy a value out of a log, a database column, or a webhook payload. You look at it — the braces line up, the quotes are all doubled, every key looks right. Then the parser says:
SyntaxError: Unexpected token '\', "\"{\"name\"..." is not valid JSONMost advice for this error tells you to hunt for a trailing comma or a stray single quote. That advice is fine, but it does not apply here — your JSON is not broken.
The problem is that you are not holding JSON at all. You are holding a string that has JSON inside it, and the parser is doing exactly what you asked: trying to read a quote character as the start of an object. This guide shows how to spot that, and how to get down to the real data.
You Are Parsing the Wrapper
A parser reads the first meaningful character and commits to an interpretation. See { and it expects an object. See [ and it expects an array. See " and it expects a plain string — and once it is reading a string, every brace and colon inside is just text.
So these two values are completely different things, even though they look almost identical:
{"name":"John"} ← an object with one key
"{\"name\":\"John\"}" ← a string that is 15 characters longParse the first and you get data you can use. Parse the second and you get a string back — you have unwrapped one layer, not reached the data. Try to read .name off it and you get undefined, which is where most of the confusion starts.
Three Things a "JSON String" Can Be
When someone hands you "a JSON string", it is one of three things, and the fix is different for each.
| What you have | Example | What it needs |
|---|---|---|
| Plain JSON | {"a":1} |
Parse once — done |
| Escaped JSON | "{\"a\":1}" |
Unwrap the quotes, then parse |
| Double-encoded | "\"{\\\"a\\\":1}\"" |
Unwrap twice |
The middle row is normal and often intentional — a JSON document stored inside a text column or a log field has to be escaped to fit. The bottom row is almost always an accident, and our guide on why JSON ends up full of backslashes covers where that extra layer comes from and how to stop it at the source.
Peeling One Layer at a Time
Here is the part that saves the most time: unwrapping removes exactly one layer per pass. It does not recurse, and that is deliberate — guessing how deep to go would risk mangling data that legitimately contains quoted text.
So a double-encoded value takes two passes. Watch the same object at three depths:
{"a":1} ← the data
"{\"a\":1}" ← escaped once
"\"{\\\"a\\\":1}\"" ← escaped twiceFeed the third one through a converter and you get the second one back — still a string, still escaped:
input: "\"{\\\"a\\\":1}\""
output: "{\"a\":1}" ← one layer gone, not done yet
input: "{\"a\":1}"
output: {"a":1} ← now it is dataIf the output still starts with a quote, run it again. If it starts with a brace or a bracket, you have arrived.
Why the Quote Style Matters
Unwrapping is not simply "delete the outer quotes". The escape sequences inside have to be reversed too, and the order that happens in matters more than it looks.
Consider a Windows path that has been through JSON twice:
"{\"p\":\"C:\\\\Users\\\\file.txt\"}"Turn \" back into " before handling \\ and you corrupt the path — the doubled backslashes get half-converted and the result is nonsense. Backslash sequences have to be resolved first, then the quotes. A converter that gets this wrong will happily produce valid-looking JSON with the wrong data in it, which is worse than an error.
This is also why pasting a value into your editor and deleting the quotes by hand tends to fail on real payloads. It works on a simple object and quietly breaks on anything containing a path, a regex, or escaped text.
When It Really Is a Syntax Error
Sometimes the JSON genuinely is malformed, and no amount of unwrapping helps. Two signals tell you which situation you are in:
- The error names a structural character — a comma, a brace, a bracket, or reports an unquoted property name. That is a syntax problem in the document itself.
- Unwrapping changes nothing — if a pass returns the same text you put in, there was no wrapper to remove and the fault is inside the JSON.
The usual culprits are trailing commas, single quotes, comments, and values like NaN that JSON does not allow. Our breakdown of formatting, minifying, and validating JSON works through each of those with examples.
One more case worth knowing: an unescaped line break inside a string value. It is invisible when you look at the text, and it produces a control-character error rather than a token error. Real newlines have to be written as \n inside a JSON string.
Unwrapping a String Into JSON
- Open the String to JSON converter.
- Drop the value in as you received it — quotes, backslashes and all. Escaped input is detected automatically, so there is nothing to strip by hand first.
- Choose Pretty to read the result or Minified to pass it along.
- Hit Parse. If what comes back still opens with a quote, feed that result in again — you were one layer deeper than you thought.
Single-quoted input works too, which helps when the value came out of a language that prefers them. Nothing is uploaded — the parsing happens on your machine.