Perfect, thanks! I looked for a long time before and couldn't find anything that seemed right.

Yeah because sanitizing client side is a great idea.

I don't think the idea is that the sanitization happens on the client when they submit content. The client can do the sanitization when they view content. Often it will make sense for the server to do it, but sometimes not. Imagine you're writing an email client web app against someone else's API, and their API gives you the raw html of email messages that people have sent to you. Then it's the client's job to sanitize that HTML for rendering.

Also you can run that library on the server with node.

yeah, i dunno why they market the lib so heavily for client-side use. but it's 2015 - js is as much server as it is client

Serious question: whats wrong with that?

I think his concern is- since the security program would need to run on the attacker's computer, the attacker may simply opt not to use it, circumvent it. That being said, I don't see why it can't be used to sanitize requests to the server.

Well, if you are worried about xss, that is a case of an attacker's code running on a victim's machine. If they process svgs through the lib before adding them to the dom, that would be one way to prevent the xss attack. This seems to be what DOMPurify are suggesting based on their documentation.

The main reason is that the server is more often than not NOT Javascript based.