XSS Input Sanitizer

Paste any HTML fragment and the XSS Input Sanitizer walks every node through an allowlist, returning only the elements and attributes that cannot carry a cross-site scripting payload. The lead sample, titled "A blog post preview", arrives with an inline onclick handler, a bare <script> tag, a javascript: href, and an onerror on an <img>. The sanitiser drops all four and returns the heading, paragraph, and link with a clean https:// href intact.

The approach is allowlist-first: 49 structural tags are permitted (headings, paragraphs, lists, tables, inline formatting elements) and everything outside that set is refused. Dangerous tags — script, style, iframe, svg, object, embed, form, link, meta, base and a further dozen — are blocked entirely: the tag and all of its children disappear. Unknown tags outside the 49 are treated more charitably: the wrapper is stripped but the text content is kept, which preserves the readable parts of a lightly malformed fragment without discarding the whole paragraph.

Every on* event handler is removed unconditionally, regardless of which tag it appears on. style attributes are dropped because CSS can carry expression() calls and url('javascript:…') values that survive a naive attribute scan. URL attributes (href, src, cite) must begin with https?:, mailto:, tel:, / or #; anything else, including bare javascript: and data URIs, is stripped. All processing runs in your browser tab with no upload.

The Controls: Safe Output and What Was Removed

1. Safe Output displays the sanitised HTML as a copyable string. If every node was dangerous the pane reads (empty — all content was unsafe) rather than silently returning a blank string.
2. What Was Removed lists three categories: tags blocked entirely with their content, tags whose wrappers were stripped while their text survived, and individual attributes that failed the allowlist or the URL scheme check. The split matters because an attacker can construct a payload inside a deeply nested custom element, so knowing the tag was removed is as important as knowing a bad href was dropped.
3. The summary bar above the tabs shows total threats removed at a glance, with separate pill counts for blocked tags and stripped attributes.
4. The collapsible Allowlist reference panel names the exact permit and block lists so you can audit what the tool considers safe before shipping output to production.

When Not to Use This as Your Only Defence

• The sanitiser uses the browser's own DOMParserto build the tree. A server-side renderer without a real DOM will not run this tool, and the output reflects how this browser's parser interprets the markup. Another engine may parse malformed HTML differently. For server-side sanitisation, use a dedicated library such as DOMPurify, which runs the same logic in Node via jsdom.
• Mutation XSS (mXSS) attacks rely on the browser re-serialising a tree differently from how it parsed it. This tool serialises with innerHTML, which is the same path mXSS exploits. DOMPurify addresses this by walking the serialised output a second time; this tool does not. Keep that in mind for HTML that will be re-parsed after sanitisation.
• Inline style attributes are dropped entirely. If your use case requires styled HTML, apply a CSS allowlist step after sanitisation, the clean structural markup this tool produces is a safe base to build on.
• Nested template elements are blocked at the tag level. Their inert content is never parsed into the live DOM by DOMParser, so removing the tag removes the threat without needing a recursive pass into the inert tree.
• Input is capped at 500,000 characters. Larger payloads would stall the main thread during the DOMParser call.