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 HT

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. Additionally, you get to use the exact same code that the browser is ultimately using to parse the HTML, so a browser parsing bug, spec nuance, or un-specced legacy behavior that your backend developer didn't consider don't turn into serious security flaws. Additionally, the Sanitize API does a much better job of handling contextual parsing then many other similar backend APIs. What happens when you parse an HTML fragment assuming it will live in a `div`, and then it actually get inserted into a `table` cell? The spec goes into this is more detail here: https://wicg.github.io/sanitizer-api/#strings https://wicg.github.io/sanitizer-api/#strings 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. Personally, I would probably still stick with Nokogiri for my own applications, but I can see both sides of the trade-off.