HTML Sanitizer API: The browser finally cleans up after you, but you'll still write regexes

Great news, everyone: the W3C has decided we've had enough of reinventing the wheel and announced the HTML Sanitizer API. Now the browser itself will strip out dangerous tags from user content, and we can cry a little less at night over XSS vulnerabilities.

What is it exactly?

It's basically a native sanitize() method that takes an HTML string and returns a safe DOM. No more DOMPurify with its 50 KB of minified code — everything comes out of the box now. Except, it's still a draft, Chrome is experimenting, and Firefox and Safari are, as usual, playing hard to get.

How it works:

1. You create a Sanitizer instance with config — which tags to cut, which attributes to ban.
2. Call sanitize(input) and get a clean DocumentFragment.
3. Insert into DOM without fear of cookie theft.

Sounds like a frontend dev's dream, right? But old browsers won't die tomorrow, so polyfills and good old innerHTML with filtering will stick around for another five years. Plus, the API is still rough — for example, you can't set custom CSP rules.

What about performance?

According to the spec authors' benchmarks, the native sanitizer is 2–5 times faster than DOMPurify because it doesn't drag a JavaScript parser along. For SPAs with lots of dynamic content, that means fewer GC pauses and happier users.

METABYTE studio's comment: We're glad browsers finally got their act together, but by the time this API stabilizes, our devs will have written another few hundred thousand lines of React. Good thing we already use DOMPurify — a habit we're not eager to break, even if the browser stepped up.