DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG.
It's also very simple to use and get started with. DOMPurify was started in February 2014 and, meanwhile, has reached version v3.4.11.
DOMPurify runs as JavaScript and works in all modern browsers (Safari (10+), Opera (15+), Edge, Firefox and Chrome - as well as almost anything else using Blink, Gecko or WebKit). It doesn't break on MSIE or other legacy browsers. It simply does nothing.
Note that DOMPurify v2.5.9 is the latest version supporting MSIE. For important security updates compatible with MSIE, please use the 2.x branch.
Our automated tests cover 9 browser/OS combinations on the current engines (Chromium, Firefox, and WebKit across Ubuntu, macOS, and Windows) on every push, and a separate matrix re-runs the suite on older engine snapshots (back to roughly Chromium 110, Firefox 108 and WebKit 16.4, around three years old) so regressions on outdated browsers get caught too. We also run Node.js v20, v22, v24, v25 and v26 with DOMPurify on jsdom. Older Node versions are known to work as well, but hey... no guarantees.
DOMPurify is written by security people who have vast background in web attacks and XSS. Fear not. For more details please also read about our Security Goals & Threat Model. Please, read it. Like, really. And if you enjoy the gory details, the Attack Classes & Bypass History page catalogs the parser-mutation, namespace, clobbering, and template tricks DOMPurify defends against.
The DOMPurify project inspired the creation of the HTML Sanitizer API, which is already shipping in many browsers. The same capability is now being standardized directly in the WHATWG HTML specification.
DOMPurify sanitizes HTML and prevents XSS attacks. You can feed DOMPurify with e.g. a string full of dirty HTML and it will return a string (unless configured otherwise) with clean HTML. DOMPurify will strip out everything that contains dangerous HTML and thereby prevent XSS attacks and other nastiness. It's also damn bloody fast. We use the technologies the browser provides and turn them into an XSS filter. The faster your browser, the faster DOMPurify will be.
It's easy. Just include DOMPurify on your website.
<script type="text/javascript" src="https://github.com/cure53/DOMPurify/raw/3.4.11/dist/purify.js"></script>
<script type="text/javascript" src="https://github.com/cure53/DOMPurify/raw/3.4.11/dist/purify.min.js"></script>
Afterwards you can sanitize strings by executing the following code:
const clean = DOMPurify.sanitize(dirty);
Or maybe this, if you love working with Angular or alike:
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize('<b>hello there</b>');
The resulting HTML can be written into a DOM element using innerHTML or the DOM using document.write(). That is fully up to you.
Note that by default, we permit HTML, SVG and MathML. If you only need HTML, which might be a very common use-case, you can easily set that up as well:
const clean = DOMPurify.sanitize(dirty, { USE_PROFILES: { html: true } });
Well, please note, if you first sanitize HTML and then modify it afterwards, you might easily void the effects of sanitization. If you feed the sanitized markup to another library after sanitization, please be certain that the library doesn't mess around with the HTML on its own. See the Security Goals & Threat Model for safe-usage recipes and the tags/attributes worth thinking twice about, and Attack Classes & Bypass History for why post-processing and changing the markup context defeat sanitization.
After sanitizing your markup, you can also have a look at the property DOMPurify.removed and find out, what elements and attributes were thrown out. Please do not use this property for making any security critical decisions. This is just a little helper for curious minds.
DOMPurify technically also works server-side with Node.js. Our support strives to follow the Node.js release cycle.
Running DOMPurify on the server requires a DOM to be present, which is probably no surprise. Usually, jsdom is the tool of choice and we strongly recommend to use the latest version of jsdom.
Why? Because older versions of jsdom are known to be buggy in ways that result in XSS even if DOMPurify does everything 100% correctly. There are known attack vectors in, e.g. jsdom v19.0.0 that are fixed in jsdom v20.0.0 - and we really recommend to keep jsdom up to date because of that.
Please also be aware that tools like happy-dom exist but are not considered safe at this point. Combining DOMPurify with happy-dom is currently not recommended and will likely lead to XSS. For background on why the server-side DOM you choose is part of your trusted computing base, see Attack Classes & Bypass History.
Other than that, you are fine to use DOMPurify on the server. Probably. This really depends on jsdom or whatever DOM you utilize server-side. If you can live with that, this is how you get it to work:
npm install dompurify
npm install jsdom
For jsdom (please use an up-to-date version), this should do the trick:
const createDOMPurify = require('dompurify');
const { JSDOM } = require('jsdom');
const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);
const clean = DOMPurify.sanitize('<b>hello there</b>');
Or even this, if you prefer working with imports:
import { JSDOM } from 'jsdom';
import DOMPurify from 'dompurify';
const window = new JSDOM('').window;
const purify = DOMPurify(window);
const clean = purify.sanitize('<b>hello there</b>');
If you have problems making it work in your specific setup, consider looking at the amazing isomorphic-dompurify project which solves lots of problems people might run into.
npm install isomorphic-dompurify
import DOMPurify from 'isomorphic-dompurify';
const clean = DOMPurify.sanitize('<s>hello</s>');
Of course there is a demo! Play with DOMPurify
First of all, please immediately contact us via email so we can work on a fix. PGP key
Also, you probably qualify for a bug bounty! The fine folks over at Fastmail use DOMPurify for their services and added our library to their bug bounty scope. So, if you find a way to bypass or weaken DOMPurify, please also have a look at their website and the bug bounty info.
How does purified markup look like? Well, the demo shows it for a big bunch of nasty elements. But let's also show some smaller examples!
DOMPurify.sanitize('<img src=x onerror=alert(1)//>'); // becomes <img src="https://github.com/cure53/DOMPurify/raw/3.4.11/x">
DOMPurify.sanitize('<svg><g/onload=alert(2)//
'); // becomes <svg><g></g></svg>
DOMPurify.sanitize('
abc<iframe//src=jAva	script:alert(3)>def
'); // becomes
abc
DOMPurify.sanitize('<math><mi//xlink:href="https://github.com/cure53/DOMPurify/raw/3.4.11/data:x,<script>alert(4)</script>">'); // becomes <math><mi></mi></math>
DOMPurify.sanitize('<TABLE><tr><td>HELLO</tr></TABL>'); // becomes <table><tbody><tr><td>HELLO</td></tr></tbody></table>
DOMPurify.sanitize('<UL><li><A HREF=//google.com>click</UL>'); // becomes <ul><li><a href="https://github.com/cure53/DOMPurify/raw/3.4.11/google.com">click</a></li></ul>
These are just a taste. For the full taxonomy of attack classes these samples come from - mutation XSS, namespace confusion, DOM clobbering, rawtext breakouts, and more - see Attack Classes & Bypass History.
DOMPurify currently supports HTML5, SVG and MathML. DOMPurify per default allows CSS, HTML custom data attributes. DOMPurify also supports the Shadow DOM - and sanitizes DOM templates recursively. DOMPurify also allows you to sanitize HTML for being used with the jQuery $() and elm.html() API without any known problems. For the exact set of elements and attributes permitted by default, see the Default TAGs & ATTRIBUTEs allow-list & blocklist wiki page.
DOMPurify does nothing at all. It simply returns exactly the string that you fed it. DOMPurify exposes a property called isSupported, which tells you whether it will be able to do its job, so you can come up with your own backup plan.
In version 1.0.9, support for the Trusted Types API (MDN) was added to DOMPurify. In version 2.0.0, a config flag was added to control DOMPurify's behavior regarding this.
When DOMPurify.sanitize is used in an environment where the Trusted Types API is available and RETURN_TRUSTED_TYPE is set to true, it tries to return a TrustedHTML value instead of a string (the behavior for RETURN_DOM and RETURN_DOM_FRAGMENT config options does not change).
Note that in order to create a policy in trustedTypes using DOMPurify, RETURN_TRUSTED_TYPE: false is required, as createHTML expects a normal string, not TrustedHTML. The example below shows this.
window.trustedTypes.createPolicy('default', {
createHTML: (to_escape) =>
DOMPurify.sanitize(to_escape, { RETURN_TRUSTED_TYPE: false }),
});
When no TRUSTED_TYPES_POLICY is supplied, DOMPurify attempts to create its own internal Trusted Types policy named dompurify. If your page already defines its own policy together with a strict CSP (for example trusted-types my-organization) that does not allow a policy named dompurify, this attempt is blocked by the browser and logs a TrustedTypes policy dompurify could not be created. warning along with a CSP violation.
To stop DOMPurify from creating its internal fallback policy, pass TRUSTED_TYPES_POLICY: null. This is the right choice when you call DOMPurify.sanitize from inside your own policy's createHTML, and it means you do not have to add dompurify to your CSP's trusted-types allowlist.
```js window.trustedTypes.createPolicy('my-organization', { createHTML: (inp
$ claude mcp add DOMPurify \
-- python -m otcore.mcp_server <graph>