HTML Sanitizer

Why raw HTML from outside sources is dangerous

Whenever a web page renders HTML that came from a user, a comment box, a CMS field, or a third-party feed, it risks running code the author of the page never intended. The classic attack is cross-site scripting (XSS): an attacker slips a <script> tag or an event handler into content, and when the page displays it, that code executes in the visitor's browser with full access to their session, cookies, and the page itself. Sanitizing means parsing the HTML and stripping out everything that could execute, while keeping the harmless formatting. This tool does exactly that, and it does it entirely in your browser using the built-in DOMParser — your HTML is never sent to a server.

How the sanitizer decides what to remove

The tool parses your input into a real DOM tree, then walks every node and applies three rules. First, it removes any element on its blocklist. By default that list is: script, iframe, object, embed, form, input, button, link, meta, base, noscript, and style — the tags that load external code, submit data, or pull in remote resources. Second, it strips every attribute whose name starts with on (such as onclick, onerror, onload), because these are inline JavaScript handlers. Third, for the URL-bearing attributes href, action, and src, it inspects the value and rewrites it to # if it begins with javascript: or data: — two schemes commonly used to smuggle executable payloads past naive filters.

Everything it touches is logged. The "Removed / Modified" panel lists each change — for example <script> removed or img[onerror] removed — so you can see precisely what was stripped rather than trusting a black box.

A worked example

Click Load example and the tool processes this snippet:

• <p>Hello <b>World</b></p> — kept untouched; paragraphs and bold text are safe.
• <script>alert('XSS')</script> — the whole element is removed.
• <img src="x" onerror="alert(1)"> — the image stays, but the onerror handler is stripped, defusing the attack while keeping the tag.
• <a href="javascript:void(0)">Click me</a> — the link text stays, but the dangerous href is rewritten to #.
• <iframe> and the <form> with its <input> — all removed.

The output is clean HTML that renders the same visible content (a greeting, an image, a link, the word "World" in bold) with every executable path neutralised.

Tuning the rules with allow and block lists

The defaults are deliberately strict, but two fields let you adjust them:

• Allow tags whitelists tags that would normally be stripped. If you genuinely need to keep <iframe> for an embedded video on a trusted page, add iframe here and it survives. Use this sparingly — every tag you re-allow is a hole you are choosing to open.
• Block extra tags removes additional tags beyond the defaults. Add video,audio to strip media you do not want, for instance.

The allowlist wins over the blocklist, so a tag that appears in both is kept.

Strip-all-tags mode

Tick Strip all tags and the tool ignores the rules entirely, returning only the plain text content of the HTML with every element removed. This is the safest possible output and is ideal when you want the words from a page without any markup — pasting rich content into a plain-text field, extracting copy for translation, or feeding text into a system that must never receive HTML.

Use cases and limits

• Cleaning user-generated content before storing or displaying comments, forum posts, or profile bios.
• Pasting from rich sources like Word or web pages, which carry hidden <style>, <meta>, and inline cruft you do not want.
• Quick security checks on a suspicious snippet to see what executable content it contains, courtesy of the removed-items log.

One important caveat: this is a practical client-side cleaner, not a hardened security boundary for a production backend. Real applications should sanitize on the server with a maintained, audited library and a strict allowlist, because attackers continually invent new vectors. Use this tool to understand, inspect, and quickly clean HTML — and treat server-side sanitization as the authoritative defence. Because all parsing happens locally, you can paste sensitive markup without it leaving your machine.