Well, it's a good thing we're not talking about DOMPurify, because the spec we're talking about (the Sanitizer API), has lots of context information and does no

Well, it's a good thing we're not talking about DOMPurify, because the spec we're talking about (the Sanitizer API), has lots of context information and does not provide a string -> string API: https://wicg.github.io/sanitizer-api/#strings https://wicg.github.io/sanitizer-api/#strings This API is simply a DOM-based whitelist for preventing script execution coupled with a contextual parser. No more, no less. It doesn't solve every problem with accepting untrusted HTML, sure, but it's good enough for a wide variety of use-cases (One example that comes up frequently is embedded markdown, another good example is a mail client—both situations where formatted, user-controlled data is important). The benefit of doing this client-side instead of server-side is that you can stay up to date with any changes that the client may make to how it's processing HTML that may have security implications. (The downsides, of course, are those associated with any thick-client/thin-server API design—more logic on the front-end means more logic to reimplement for different consumers)