The browser’s built-in HTML Sanitizer API: goodbye, DOMPurify? 🛡
Native HTML sanitization: safe and unsafe methods, use cases, the backend’s role and browser support.
We have all rendered user content through innerHTML at some point and fought XSS vulnerabilities. DOMPurify has always been the de facto standard for cleaning HTML. It is an excellent tool, but it brings ~23 KB of code into the bundle and has to duplicate the browser’s parsing work, constantly catching up with new web-platform features.
Ahmad Alfy’s blog has published an excellent breakdown of the new HTML Sanitizer API, which finally moves sanitization into the browser itself.
The main points from the article:
- Two families of methods: safe (
setHTML,parseHTML) and unsafe (setHTMLUnsafe,parseHTMLUnsafe). - Safe by default:
setHTML()is extremely strict. It strips out any dangerous tags andon*attributes, even if you try to explicitly allow them through the configuration object. - Unsafe methods as an escape hatch:
setHTMLUnsafe()is useful if you need to pass through Declarative Shadow DOM, or fully understand why you are deliberately allowing inline scripts. - Ideal use cases: Optimistic UI, safely rendering a comment on the client immediately while waiting for the server response; cleaning messy HTML on paste, for example from Word; and Markdown previews.
- The backend still matters: the client-side Sanitizer API is about UX and immediate protection in the browser. Basic data sanitization on the backend is still necessary.
What about support?
In February 2026, Firefox 148 was the first to ship a stable implementation. Chrome still hides the feature behind a flag, while Safari has only expressed a positive position, without active development. Until the API reaches Baseline, use feature detection and keep DOMPurify as a fallback.
When do you think we will be able to remove DOMPurify from production entirely? Or will the long tail of older browsers keep us tied to it for another five years? 👇