Every codebase has one. Somewhere in a component nobody has opened in eighteen months, there is a line that reads el.innerHTML = someValue, and nobody can tell you with confidence where someValue comes from. Maybe it's a hardcoded template. Maybe it's a server response. Maybe, three refactors ago, it started carrying a slice of location.hash. That uncertainty is the entire DOM XSS problem: the sink is a plain string setter, strings all look alike, and the browser has no way to tell a trusted one from an attacker-controlled one.
Trusted Types fixes that by refusing strings outright. And as of February 2026, when Firefox 148 shipped support, it's Baseline — Chrome and Edge have had it since 83 back in 2020, Safari joined in version 26, and now the whole core browser set is covered. It's no longer a Chrome-only hardening trick you bolt onto an internal admin tool.
Turning a whole class of bug into a runtime error
The API works by locking down the risky sinks: innerHTML, outerHTML, insertAdjacentHTML, document.write, DOMParser.parseFromString, <iframe srcdoc>, script src and text content, and the code-compiling family (eval, new Function(), string-argument setTimeout and setInterval). Once enforcement is on, passing a raw string to any of them throws a TypeError.
