HTML Sanitizer
Sanitize and clean HTML by stripping XSS vectors, scripts, event handlers, and unwanted tags.
Preview
What is an HTML Sanitizer?
An HTML sanitizer is a tool that takes untrusted HTML and removes the parts that can harm a page or its visitors. Instead of displaying whatever markup is pasted in, it parses the markup with the browser's native DOM parser, walks every element pair, and drops the tags, attributes, and values that are known to introduce security or layout problems. The result is a cleaned fragment that still renders as ordinary HTML but no longer carries hidden executable content.
This particular sanitizer focuses on the classic cross-site scripting (XSS) vectors. It can strip <script> and <style> blocks, remove <iframe>, <embed>, <object> and <applet> elements, delete <a> and <img> tags, and erase every inline event handler attribute such as onclick or onerror. It also removes attributes whose value begins with a dangerous URL scheme, including javascript:, data:, vbscript: and file:, and it can remove HTML comments entirely.
Beyond the block list, the tool supports an allowlist. When you type a comma-separated list of tag names into the Allowed Tags field, only those tags survive; every other tag is unwrapped. Unwrapping a removed non-void element keeps the text inside it but discards the tag itself, so formatting can disappear while the readable content remains intact. Genuinely void elements such as <br>, <hr> and <img> are removed whole because they have no closing tag.
Because all of this runs in the browser with the native DOM, nothing is uploaded and the operation is instant. It is a convenient way to preview how HTML looks after cleaning, to prepare snippets for safe embedding, or to compare input and output side by side. That said, a client-side sanitizer is a best-effort convenience, not a server-side security guarantee. For anything that reaches production or other users, always re-validate and sanitize on the server with a battle-tested purifier and a strong Content Security Policy.
Key Concepts
- DOM parsing — the input is parsed into a real DOM tree so attributes and nesting are understood, not treated as plain text.
- Block list — script, style, iframe, embed, object and applet tags are removed on request.
- Event handlers — attributes beginning with
on(likeonclick) are stripped. - URL schemes — values starting with
javascript:,data:,vbscript:orfile:are dropped. - Allowlist — only the comma-separated tags you specify are kept; others are unwrapped.
- Best effort — client-side cleaning is a convenience, not a substitute for server-side validation.
How to Use
- Paste your HTML — Put the markup you want to clean into the Input HTML textarea.
- Choose removal options — Tick the checkboxes for the elements and attributes you want stripped, such as scripts, events, or iframes.
- Set allowed tags — Optionally enter a comma-separated whitelist so only those tags are kept and everything else is unwrapped.
- Run sanitize — Click Sanitize to parse the markup and produce the cleaned HTML with before and after byte sizes.
- Review and copy — Inspect the sanitized output and live preview, then copy the result.
Sanitizer Options Reference
| Option | What it does | Typical example removed |
|---|---|---|
| Remove <script> | Deletes every script element and its contents. | <script>alert(1)</script> |
| Remove <style> | Deletes style blocks that could alter layout. | <style>body{display:none}</style> |
| Remove Events | Strips attributes whose name starts with on. | onclick, onload, onerror |
| Remove <iframe> | Removes iframe and embed elements. | <iframe src="..."></iframe> |
| Remove <object> | Removes object, embed and applet elements. | <object data="..."></object> |
| Strip Dangerous Attrs | Drops attributes with dangerous URL schemes. | href="javascript:..." |
| Remove Comments | Deletes HTML comment nodes. | <!-- hidden note --> |
| Remove Links | Removes <a> tags, keeping their text. | <a href="...">text</a> |
| Remove Images | Removes <img> tags entirely (void element). | <img src="x" onerror="..."> |
| Allowed Tags | Comma-separated allowlist; any tag not listed is unwrapped. | p,br,strong,em,ul,li |
| Dangerous schemes | Always considered unsafe when attribute stripping is on. | javascript:, data:, vbscript:, file: |
Worked Examples
- Script block —
<div>Hi<script>alert(1)</script></div>becomes<div>Hi</div>when script removal is on. - Inline event handler —
<button onclick="steal()">Go</button>becomes<button>Go</button>. - JavaScript URL —
<a href="javascript:alert(1)">x</a>loses the dangeroushrefattribute when attribute stripping is enabled. - Unwrapped tag — with an allowlist of
p,strong, the input<h2>Title</h2>becomes plainTitle, because heading tags are not allowed. - Image with onerror —
<img src="x" onerror="alert(1)">is removed whole when image removal is enabled. - Comment removal —
<!-- secret --><p>ok</p>becomes<p>ok</p>when comment removal is checked.
Tips and Common Mistakes
- Client-side is not a security boundary — use this to preview and prepare content, but always sanitize again on the server before rendering user input.
- An allowlist is safer than a block list — keeping only the tags you truly need removes far more attack surface than removing a few known-bad tags.
- Unwrapping keeps text, not formatting — when a tag is not in the allowlist its content survives but the styling disappears, which can surprise you.
- Watch the byte-size delta — the before-and-after size shows how much was removed, but a small removal count does not guarantee semantic safety.
- Allowlist entries are tag names only — enter names like
p,strong, not full tags or attributes. - Combine with a CSP — a strong Content Security Policy adds a second layer of defense if a vector ever slips through.
Common Use Cases
Cleaning HTML shows up wherever untrusted markup meets a rendered page. These are the situations where a quick sanitize step saves time and reduces risk.
- Previewing user submissions — see how pasted markup will look after risky pieces are removed before it ever reaches your app.
- Cleaning CMS pastes — strip editor cruft, stray scripts and inline handlers from content copied out of other systems.
- Preparing email or embedded snippets — remove iframes, scripts and events that mail clients and embeds will not run anyway.
- Sanitizing comments and forum posts — reduce the XSS surface of user-generated content with an allowlist.
- Debugging injection issues — compare input and output to confirm which tag or attribute carried the problem.
- Learning about XSS vectors — experiment with payloads to understand how sanitization neutralizes them.
Frequently Asked Questions
Does this completely prevent XSS?
No. A client-side sanitizer reduces many attack vectors but cannot be a guarantee. Any content that reaches production should be re-validated and sanitized on the server with a maintained purifier and a strong Content Security Policy.
Can I allow specific tags only?
Yes. The Allowed Tags field takes a comma-separated list of tag names. Only those tags are kept; every other tag is unwrapped so its text remains but the tag is discarded.
How is sanitization performed?
Sanitization runs entirely in your browser using the native DOM parser. The input is never uploaded, so the process is private and instant.
Which tags can be removed?
The checkboxes remove script, style, iframe, embed, object and applet elements, plus a and img tags, along with inline event handlers and dangerous attribute values.
What happens to text inside a removed tag?
For non-void tags that are unwrapped, the inner text is preserved and only the tag is removed. Void elements such as img or br are removed completely because they have no closing tag.
What are dangerous URL schemes?
Attribute values beginning with javascript:, data:, vbscript: or file: are treated as dangerous and dropped when attribute stripping is enabled, because they can execute or load untrusted content.
What do the before and after byte sizes mean?
They show the length of the input HTML compared with the sanitized output, so you can see how much was removed and how much cleaner the result is.
Is my HTML sent anywhere?
No. Everything happens locally in your browser tab. No input, output, or metadata leaves your device.