The problem was never a secret. Every web developer who's spent time wrestling with user-generated content knows the dance: You need to inject HTML into the page, innerHTML is sitting right there, effortlessly convenient—and utterly dangerous if you're not careful. For years, the solution has been libraries. DOMPurify. js-xss. A whole ecosystem built around sanitizing what the browser should have protected from the start.
Mozilla thinks that era might be ending.
On February 24, 2026, Firefox 148 became the first major browser to ship the standardized Sanitizer API with its centerpiece method, setHTML(). It's a deceptively simple pitch: Replace innerHTML with something that strips out cross-site scripting vectors automatically. No external dependencies. No configuration gymnastics. Just safer defaults, baked into the browser itself.
Whether other browsers follow suit quickly enough to matter is another question entirely.
The Core Proposition
Here's what setHTML() does, stripped down to its essence: It parses HTML and removes anything that could execute code before inserting it into the DOM.
Where innerHTML blindly accepts whatever string you feed it—<script> tags, event handlers, the full rogues' gallery of XSS attack vectors—setHTML() runs that input through a filter. Elements like <script>, <iframe>, <embed>, and <object> get stripped. Every event handler attribute disappears. According to Mozilla's documentation, this happens regardless of any custom configuration you might pass. There's a hard floor on what the browser considers safe.
The official Firefox 148 release notes frame it plainly: "Firefox now supports the Sanitizer API… element.setHTML()." Mozilla positions the feature alongside Trusted Types support as part of a security-focused update, though the accompanying Mozilla Hacks blog post—written by Tom Schuster, Frederik Braun, and Christoph Kerschbaumer—takes a more direct stance. Its title: "Goodbye innerHTML, Hello setHTML."
That's not subtle positioning. It's a call to action.
Context-Aware Sanitization
The technical approach matters more than it might seem at first glance.
The Sanitizer API operates at the DOM level, not as a string processor. When you call element.setHTML(htmlString), the browser parses the HTML in context, applies sanitization rules, then inserts only the safe fragments. That parsing context is critical. String-based sanitizers can fall victim to mutation XSS (mXSS) attacks, where the parser interprets markup differently than the sanitizer expected. By working on the parsed DOM instead of raw strings, setHTML() sidesteps entire classes of those attacks, according to the WICG specification that defines the API.
For most developers, the default configuration should suffice. But the API allows custom Sanitizer objects if you need stricter allowlists or want to block additional elements beyond the always-unsafe defaults. Even then, there are limits. The spec explicitly prevents custom configurations from overriding the implicit removal of dangerous elements. You can tighten the screws, but you can't loosen them past a certain point.
The Mozilla Hacks post includes a straightforward example: setHTML() strips an <img> tag carrying an onclick handler while preserving a harmless <h1> element. Simple, but it demonstrates the point. Safe by default, surgical in execution.
The Escape Hatches
Mozilla hasn't eliminated all flexibility. The API includes unsafe variants like setHTMLUnsafe() for edge cases where developers genuinely need specific elements or attributes that would otherwise be blocked. The documentation frames these methods with appropriate caution—use them only when there's a documented need, and understand what you're opting into.
It's deliberate design philosophy. The pattern is sometimes called the "pit of success": Make the safe path the easiest path, and require explicit acknowledgment for dangerous operations.
Developers can also instantiate Sanitizer objects directly, configuring allow and deny lists through the SanitizerConfig interface. These configurations are exportable and reusable across multiple injection points, which could be useful for teams with consistent sanitization requirements across a large codebase.
Layered Defenses
Firefox 148 doesn't just ship the Sanitizer API in isolation. It also introduces support for Trusted Types, the CSP-based enforcement mechanism Google developed for tracking dangerous DOM sinks—places in your code where unsanitized data could turn into XSS vulnerabilities.
The timing isn't coincidental. The Mozilla Hacks post recommends a two-stage approach: Adopt setHTML() first, then enable Trusted Types enforcement through Content Security Policy headers to block other unsafe sinks and prevent regressions. The safe sanitization methods (setHTML, parseHTML) don't count as Trusted Types sinks under this model, so they won't require special handling once enforcement is active. The unsafe variants, however, will be flagged by the Trusted Types system, making them easier to audit.
It's defense in depth, browser-native style. Perhaps the most significant shift Mozilla has made in this space since Firefox introduced mixed content blocking years ago.
The Fragmentation Problem
Here's where Firefox's leadership position becomes complicated.
The Sanitizer API has limited support across browsers, according to Can I Use data and developer posts from late 2025. Chrome actually shipped an earlier variant around Chrome 105 back in 2022, then pulled it as the specification continued evolving. WebKit has signaled a positive position but hasn't committed to a shipping timeline. Safari, in other words, remains a question mark.
That leaves production developers in an awkward spot. You can't just swap innerHTML for setHTML() and ship it if a significant chunk of your users are on browsers that don't support the API. Feature detection becomes mandatory. MDN recommends checking for 'setHTML' in Element.prototype and falling back to established libraries like DOMPurify when the API isn't available.
Mozilla even maintains a sanitizer-polyfill that wraps DOMPurify to emulate the API shape, though the project carries no production-stability guarantees. It's a bridge solution until broader adoption materializes—if it materializes.
The reality is that Firefox 148 makes the API real, but it doesn't make it universal. At least not yet.
What Adoption Looks Like
For teams that decide to move forward, the migration mechanics are straightforward. Replace element.innerHTML = untrustedString with element.setHTML(untrustedString). That's the base case, and for many applications, it'll be sufficient.
If you're already running every innerHTML assignment through a sanitization library, you'll need to evaluate whether the browser's built-in sanitizer meets your requirements. In most scenarios, it should. Teams with specialized needs might still want custom Sanitizer configurations or continued use of battle-tested libraries with proven track records.
The challenge isn't the code change itself. It's compatibility. Until Chrome and Safari ship their implementations, developers building for the open web will need those feature detection branches and fallback strategies. That means maintaining two code paths—one for Firefox users who get native sanitization, another for everyone else who gets the library-based approach.
It's worth noting that this isn't Mozilla's first attempt at pushing the web platform forward on security without unanimous browser support. Sometimes those efforts gain momentum. Sometimes they don't. The difference here is that the Sanitizer API solves a problem every web developer acknowledges, which might accelerate adoption. Or it might not. Chrome and Safari's timelines will ultimately determine whether this becomes a standard feature or a Firefox-specific enhancement.
For now, though, developers have a choice they didn't have before. Whether enough of them make it to force the issue remains an open question.
