b2KIT

HTML Sanitizer & XSS Cleaner

Sanitize HTML input by removing dangerous tags, attributes, and event handlers. Preview safe output in an isolated iframe.

Tested tool guide Tested browser tools Checked August 16, 2026

What HTML Sanitizer & XSS Cleaner does and how it behaves

Pasted markup is treated as content to clean, not as a page to trust. The HTML Sanitizer & XSS Cleaner removes dangerous elements, unsafe attributes, and inline event-handler attributes, returns the remaining HTML, and renders that result in an isolated iframe for inspection. The common surprise is that a harmless-looking preview is not a universal security verdict. HTML safety depends on where the result is later inserted and whether another step decodes, concatenates, or modifies it. Review the returned markup, not just its appearance, before using it elsewhere.

How the result is produced

1

Markup cleaning

The cleaner evaluates the submitted HTML fragment against its sanitization policy. It removes dangerous elements, unsafe attributes, and inline event-handler attributes while leaving permitted markup available as output. Compare the source and result directly: the absence of an active effect in the preview does not reveal every discarded input token, and surviving text does not prove that its original enclosing element survived.

2

Isolated preview

The preview renders the cleaned result, rather than the original input, inside an isolated iframe. This provides a bounded place to inspect how the surviving markup behaves without inserting the submitted fragment directly into the surrounding tool page. That isolation applies only to this preview. The same output may render differently when copied into a document with different styles, scripts, permissions, or surrounding markup.

Good uses

  • Clean a rich-text fragment copied from a CMS before examining or republishing its HTML.
  • Compare the original and sanitized forms of a third-party widget, template, or email fragment during an XSS-focused review.
  • Test whether a minimal suspected payload, such as an element carrying an inline event handler, survives the cleaner.

Limits and checks

  • Sanitization policies are not interchangeable. A fragment accepted here is not automatically accepted, rejected, or considered safe by another sanitizer with a different policy.
  • A quiet iframe preview does not prove that every surviving construct is suitable for the eventual destination. Deployment context can change how otherwise identical markup behaves.
  • The result is cleaned for use as HTML. Later decoding it or concatenating it into JavaScript, CSS, URLs, or HTML attributes creates a different context with different risks.

Common questions

Does a clean result make user-supplied HTML safe to store and publish?

No, not by itself. The result is a cleaned fragment under this tool's policy, but publication safety also depends on the destination context and later processing. Validation or sanitization at the application's trust boundary remains appropriate, especially for stored input. Do not place the result inside JavaScript, CSS, or a URL and assume HTML sanitization covers that context.

Will sanitizing preserve the original appearance and behavior?

Not necessarily. Any tag or attribute categorized as dangerous can disappear, so interaction, embedded content, or presentation attached to that markup may change. The isolated preview helps reveal visible breakage, but inspect the cleaned source as well. Removed metadata, event handlers, or structural elements may not produce an obvious visual difference.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools