Chrome 146 Sanitizer API: safer HTML without XSS shortcuts

A CMS delivers a paragraph with formatting. The frontend displays it. Routine work—until the HTML contains code the browser might execute. Chrome 146’s Sanitizer API offers a safer way to render rich text, but why are we interpreting this data as HTML in the first place?

The problem starts at the insertion point

Using innerHTML with untrusted content can expose a website to cross-site scripting (XSS). Fetching data through an API is not inherently dangerous; interpreting untrusted markup as active HTML is. For ordinary titles, labels and notices, textContent is safer because it treats the value as text.

container.innerHTML = cmsContent;
container.textContent = userInput;

When formatting really is required

Editorial content may need links, paragraphs and lists. Element.setHTML() parses markup and removes content considered unsafe for XSS. Chrome announced the updated Sanitizer API in March 2026, and Firefox support was also reported. The example below is based on official documentation and was not independently executed in a browser.

const container = document.querySelector('#article');
const cmsContent = `<p>Hello</p><img src="x" onerror="alert('XSS')">`;
container.setHTML(cmsContent);

A sanitizer cannot replace content policy

Define which fields accept plain text and which require rich HTML. A label should not unexpectedly process markup, while a dedicated rich-content component can use a documented policy. Include previews, plugins and administration screens in the same review.

Plan for browsers without setHTML

MDN reports limited availability. Detect the actual method in each supported browser and webview. Where unavailable, use a maintained, correctly configured sanitizer fallback. Never silently use unsanitized innerHTML.

if ('setHTML' in Element.prototype) {
  container.setHTML(cmsContent);
} else {
  // Use a reviewed, safely configured sanitizer fallback.
}

Test legitimate content as well as malicious input

Test event handlers, unexpected tags and unsafe link schemes, but also real links, lists and tables. Check keyboard interaction and assistive technologies. Content Security Policy, contextual escaping and Trusted Types can provide additional layers.

The strongest improvement is often processing less untrusted HTML at all. Minimise the insertion points that parse external HTML and protect the ones you cannot avoid.

CMS architecture

Sources

• Chrome Developers — New in Chrome 146
• MDN — Element.setHTML()
• MDN — HTML Sanitizer API