There is a special kind of frustration reserved for the error that points at the wrong character. A parser once told me Expected ',' or '}' after property value in JSON at position 205, and position 205 was a perfectly innocent colon. The actual crime had been committed sixty characters earlier, by a pair of quotation marks around the words "Golden Gate." Fixing unescaped quotes inside JSON string values starts with understanding why the parser lies to you about where it happened.
The quote that ended the string early
Here is the pattern. Somewhere in your data there is a sentence that quotes something, and the quotes went in raw instead of escaped:
{
"note": "Meet at "Golden Gate" bridge at noon"
}The parser reads the string, hits the quote before Golden, and decides the string is over. Now it is staring at Golden where it expected a comma or a closing brace, and it reports the error wherever the wreckage becomes undeniable. That is why the position in the message is rarely where the fix is. The instinct is to scroll to the reported position and squint. The better move is to scroll backwards from it and look for a quote with prose on both sides.
The repair rule: what counts as a real closing quote
A closing quote is only a closing quote when the character after it (ignoring whitespace) is structural: a comma, a colon, a closing brace, a closing bracket, or the end of the input. Anything else after a quote means you are still inside the string, and that quote should have been escaped. That one sentence is the entire repair algorithm, and it is how several real parser-repair tools handle LLM output, which is where most of these errors now come from. I have seen the same state machine described in three different open-source projects this year, all written independently, all converging on the same lookahead rule. When three unrelated codebases invent the same fix, the rule is probably correct.
The fixed version of the example above is:
{
"note": "Meet at \"Golden Gate\" bridge at noon"
}The wrong fix, which I tried first
My first attempt at this, years ago, was to strip every quote that was not at the start or end of a value. It worked on the test case and destroyed real data. The problem: a value like "size": "3\" x 4\" photo" has quotes that look structural to a naive regex but are legitimate escaped content, and a value like "label": "a "quoted" word" cannot be fixed by deletion without changing the meaning. There is also a case nothing can recover: a quote immediately before a comma is genuinely ambiguous, because "word", is exactly what a correctly closed string looks like. The honest repair tools document this as a known limit. If you ever build this yourself, that ambiguity is where you stop and retry the generation instead of guessing.
How to fix unescaped quotes in a JSON string value
For a one-off document, the manual fix takes a minute. Find the error position the parser reported, scan backwards for the nearest quote that has text (not punctuation) after it, and add the backslash: \". Then re-parse. There is often a second one hiding nearby, because whatever produced the first unescaped quote tends to produce them in runs.
For documents generated by a language model, fix the pipeline instead of the document. Two defenses, in order of reliability. First, tell the model explicitly to never put double quotes inside string values, and suggest an alternative like single quotes or corner brackets for the content it wants to quote. This eliminates the large majority of cases. Second, run the lookahead repair as a fallback before parsing: walk the text, and when inside a string, escape any quote whose next non-whitespace character is not structural. Valid JSON passes through byte-identical, so it is safe to run on everything.
And for data you generate yourself in code, never hand-assemble JSON. JSON.stringify in JavaScript and json.dumps in Python escape inner quotes automatically. The bug is almost always a sign that a string was concatenated into JSON by hand or written by a model.
A grudge, briefly
JSON gets called brittle for rejecting this, and I think that is unfair. The strictness is what makes the repair rule above possible: because a real closing quote is always followed by structure, the ambiguity is bounded and recoverable. A lenient format would accept the broken document and silently assign the wrong value, which is worse in every way that matters. I will take a loud parse error over quiet data corruption any day.
Paste your broken JSON into the repair tool and it will flag unescaped quotes and show you exactly what it changed.
Frequently asked questions
Is an unescaped quote valid in a JSON string?
No. RFC 8259 requires a quotation mark inside a string to be escaped as \". A raw " always terminates the string, which is why one stray quote can invalidate a whole document.
Why does the error position point at the wrong character?
The parser does not fail at the unescaped quote. It treats that quote as the end of the string and only fails later, when the remaining text stops making grammatical sense. Scroll backwards from the reported position to find the quote with prose on both sides.
Can I fix this with a regular expression?
A careful one, yes. The rule is to escape a quote only when the next non-whitespace character is not a comma, colon, closing brace, closing bracket, or end of input. A naive regex that deletes or escapes all inner quotes will mangle escaped quotes that were already correct.
How do I stop a language model from emitting unescaped quotes?
Add an explicit instruction: no double quotes inside string values, use single quotes or another marker for quoted phrases in the content. Then run the lookahead repair as a fallback before parsing, since instructions reduce the error rate but do not eliminate it.
Get one practical dev-tools guide a week: subscribe to the newsletter for new JSON guides and parser explainers.
Related reading: How to Fix the JSON Single Quotes Error · The Trailing Comma That Breaks Your JSON · Why Is My JSON Invalid? · NDJSON Broke My Parser