Google stops undoing double HTML escapes in JSON-LD

Since August 21, 2026, Google applies a single pass of HTML unescaping when it reads JSON-LD. Normal HTML escaping still works (it would make no sense if it didn't); the problem is the double escapes produced by some CMSs, minification plugins and CDNs: Google used to undo them and now leaves them as unreadable text in your structured data.

Google has changed the way it reads structured data on pages. Since August 21, 2026, it undoes HTML escapes in JSON-LD only once, instead of as many times as needed. If your site has them escaped twice, something many caching, minification or structured data plugins do without telling you, Google no longer reads them correctly. And no tool flags it yet.

JSON-LD doesn't live in a separate file: it's inserted inside the page's HTML. That's why two ways of escaping characters coexist: HTML's (&, é, ✔) and JSON's own (\", \n, \u0026). Until now Google was lenient: if an HTML entity came escaped twice, it undid it until it reached the character. Now it undoes it once and whatever is left is read as is.

Google Search Central announced it on August 21 in a LinkedIn post: "to bring our parser up to JSON and other standards, we changed our JSON-LD extraction and now apply a single pass of HTML unescaping". Google's Gary Illyes added the same day that proper escaping in JSON is defined in section 7 of RFC 8259.

There's some truth in the fuss, and also some exaggeration. Google still reads normal HTML escapes; what it no longer reads are double ones, which are almost never written by hand: they're produced by a CMS that escapes what was already escaped, a caching or minification plugin, a JSON plugin or a CDN that minifies the HTML. A trick to spot them: if a "word" starting with & appears inside the text of a JSON, it's an HTML escape; if that word starts with &, it's a double one.

What Google now does with each type of escape inside a JSON-LD:

Part of the confusion comes from how Google's message was reproduced. In the version published by Search Engine Roundtable, and in others that copied it, the examples appear as & and ✔, that is, with a single escape: the outlet's own CMS undid the double escape of the original. Read that way, it looks as if Google stops accepting normal HTML escaping, and that's not it. In Google's original message the examples are & and ✔: double escapes. &, which is still valid, is not the same as &.

The same JSON-LD twice in the Rich Results Test: with single HTML escapes Google reads «Máster SEO Técnico & GEO»; with double escapes the name is left as «Máster SEO Técnico & GEO». Both items are considered valid: the tool doesn't warn you.

That's the dangerous part: it used to be read correctly and now different, unreadable text would show, and no tool flags it yet. The Rich Results Test still marks the item as valid, because syntactically it is; you have to look at the text it shows under "Detected items" to see whether the name of the product, course or company has come out with junk in it.

The fixed version: the same block with standard JSON escapes. Checking it page by page is slow; at scale you have to crawl.

Checking it is neither automatic nor quick. For a single page, the Rich Results Test: if you see & or é written out as is in the detected items, you have the problem. For a whole site, a Screaming Frog crawl with a custom search or a regex extraction on the application/ld+json blocks: any & followed by amp;, quot;, # or the name of an entity is a double escape. Anyone using minification plugins (many caching plugins do it), plugins that generate JSON or a CDN that minifies HTML has the most reasons to crawl.

The fix isn't to remove HTML escaping, which is still valid, but to repair the chain that doubles it: usually a call to htmlspecialchars (or its equivalent) on text that was already escaped, or on the output of json_encode. The most robust approach, and the one Google asks for, is to generate the JSON-LD with JSON's own escapes (\u0026 for the ampersand, \" for quotes) and not run that block through any HTML escaping afterwards.

The summary, posted on LinkedIn the same day:

Carlos Sánchez's LinkedIn post about Google's change to JSON-LD escaping

References

1. Bray, T. (2017, December 1). The JavaScript Object Notation (JSON) Data Interchange Format, section 7: Strings. rfc-editor.org. https://www.rfc-editor.org/rfc/rfc8259#section-7 (the JSON escaping standard Google refers to)
2. Google (n.d.). Rich Results Test. https://search.google.com/test/rich-results (the tool used for the screenshots in this article)
3. Google Search Central (2026, August 21). To bring our parser up to JSON and other standards, we changed our JSON-LD extraction [LinkedIn post]. https://www.linkedin.com/feed/update/urn:li:share:7496492350370713600/ Main source
4. Illyes, G. (2026, August 21). If you're wondering what proper escaping is in JSON, it's very well defined in RFC 8259 [LinkedIn post]. LinkedIn. https://www.linkedin.com/posts/garyillyes_if-youre-wondering-what-proper-escaping-share-7496494336604360705-8Ram/ (Google's clarification on proper escaping)
5. Schwartz, B. (2026, August 21). Google Changes JSON-LD Extraction For Googlebot. Search Engine Roundtable. https://www.seroundtable.com/json-ld-extraction-googlebot-41921.html (covers the announcement; in its text the double escapes in Google's message come out collapsed)