HTML Sanitizer Preview — Inspect Cleaned Markup

An HTML sanitizer preview accepts pasted markup, removes active or disallowed constructs, and rebuilds a limited document using approved elements and attributes. This workspace discards scripts, inline event handlers, external media, forms, embedded frames, SVG, styles, and unsupported URL schemes before displaying the output as text and in a sandboxed preview. It also reports how many elements and attributes were removed. The result is intended for inspecting the effects of a transparent, restricted policy; it is not a guarantee that the same HTML can be inserted safely into every application or rendering context without additional production safeguards.

Sanitize HTML Online At a Glance

What Sanitizing HTML Actually Means

HTML sanitization is the process of taking potentially untrusted markup and allowing only a defined subset of it to remain. A sanitizer must decide not just which tags are acceptable, but which attributes are safe on those tags and which URLs should be permitted. Removing a script tag alone is not sufficient, because browser execution paths can also appear in event attributes, dangerous URL schemes, embedded documents, or parsing edge cases. This tool uses a deliberately narrow allowlist and reconstructs output nodes rather than attempting to remove a few suspicious strings with a regular expression. That distinction is crucial: the objective is a predictable document structure, not a visual illusion of cleaned text.

Why an Allowlist Is Easier to Reason About

An allowlist says that a paragraph, emphasis, heading, list, or selected table element can be retained, while unrelated elements have no automatic permission. A blocklist tries to enumerate everything dangerous and is more likely to miss an unexpected construct as browser features evolve. The sanitizer keeps familiar reading structures, including paragraphs, strong and emphasized phrases, code, block quotes, headings, and basic tables. It drops active elements and external resources outright. Unsupported wrapper elements may be flattened to preserve harmless textual content, so readers can still see the words without retaining the original element's presentation behavior or interactive role.

Handling Links Without Dangerous URL Schemes

A link is not harmless solely because its element name is allowed. An anchor whose href begins with a script-based scheme could execute code if a user activates it, while obscure controls and encoded characters can make raw string checks unreliable. The link filter trims candidate destinations, rejects control characters, and accepts only ordinary HTTP, HTTPS, mailto, or tightly defined local fragment URLs. It does not preserve JavaScript URLs, custom app schemes, credentials embedded in URLs, or arbitrary fragments. Retained anchors receive rel values intended to reduce some follow-on browser risks. These decisions should be reviewed against the link types your own application genuinely needs.

Attribute Filtering and the Role of Event Handlers

Attributes can change the behavior of otherwise benign-looking tags. An onclick attribute on a paragraph, an onerror handler on an image, or a style attribute with unexpected resource references cannot be evaluated safely by simply trusting the surrounding tag. This workspace does not copy arbitrary attributes from input nodes. It permits a small group, such as validated link destinations and selected table scope or span attributes, while rejecting event handlers, element IDs, style directives, data attributes, and script-triggering behavior. Its removal report counts these decisions so a reviewer can see that seemingly minor formatting differences may correspond to important safety rules.

Why Images, SVG and Forms Are Removed

Images and embedded elements are useful in rich publishing systems, but they greatly expand the surface that a sanitizer needs to evaluate. Image URLs can create network requests, SVG can contain complex markup, and forms can submit data or encourage misleading interactions. This limited workspace chooses not to support those elements at all. A production editor that needs photographs or interactive widgets requires additional audited rules, URL rewriting, content storage decisions, and browser isolation. It is safer to acknowledge those requirements than to enable rich content behind an inadequately tested policy. The preview intentionally prioritizes restrained reading markup over reproducing the appearance of the original input.

What the Sandboxed Preview Can and Cannot Show

The visual preview uses an iframe without sandbox privileges and includes a restrictive content-security policy inside the preview document. The browser can render the approved structure as text, lists, and tables, but scripts and ordinary external resource loads are blocked. The exact serialized HTML also appears separately so reviewers can see the actual output rather than judging only how it looks. The iframe is not the destination application's renderer: an email client, content management system, mobile WebView, or HTML-to-PDF engine may parse and style the same markup differently. Always validate the eventual insertion context independently.

Example: Cleaning a Pasted Product Description

Consider a product description copied from a supplier's dashboard. It contains an h2 title, two paragraphs, a benefits list, a hyperlink, and a hidden tracking image with an onload handler. After sanitization, the heading, readable prose, list, and permitted hyperlink remain, but the image and event attribute do not. The output is easier to inspect because active and decorative markup are removed. Before publication, check whether required legal notices, trademark symbols, or comparison tables are still readable, since removing unsupported wrappers may change spacing. Security filtering should not silently change the factual meaning of marketing or technical claims.

Preserving Accessibility in Cleaned Content

Sanitizing markup and making it accessible are related but separate tasks. The policy can preserve semantic headings, lists, table header cells, and scope attributes, yet a well-formed tree can still have an illogical reading order or unclear link text. If a table uses complex header relationships, the basic table allowlist may not retain every relationship needed by assistive technology. A table accessibility checker can flag some of those structural issues, but human review is still required for meaning, labels, and visual comprehension. Do not assume that absence of active code equates to good accessibility or editorial quality.

Exporting Clean HTML and Reviewing Removed Constructs

Copying the result transfers the sanitized HTML string, not the original source. The download includes the same serialized markup, and the JSON report preserves removal counts and the declared allowlist policy. Keeping the original separately can be valuable for debugging, especially when a legitimate piece of information disappeared. Compare the two versions in a safe text editor and decide whether the publishing application needs a revised policy or different authoring markup. Avoid loosening the sanitization rule merely to make a single pasted sample look identical; compatibility decisions should account for the full range of expected inputs and the application's threat model.

Security Limitations of a Demonstration Sanitizer

HTML parsing and injection defense involve browser-specific behaviors, context-sensitive encoding, and libraries that receive ongoing security maintenance. A preview sanitizer cannot be considered a fully audited defense for a production rich-text field or comment system. It does not implement a full HTML sanitization standard, remove risk from every possible downstream transformation, or address server-side template injection. The safest workflow is to use a maintained, thoroughly tested sanitizer appropriate to the insertion context, alongside CSP, server validation, and secure output handling. Treat this workspace as a controlled way to observe common sanitization effects and identify unexpected changes before applying a production policy.

Nested Markup and Text Preservation

Untrusted snippets often contain deeply nested containers, malformed closing tags, or copy-pasted fragments from word processors. The browser's parser first turns that source into a document tree, which may not have exactly the nesting implied by the original text. The sanitizer then walks the parsed structure and creates a fresh restricted tree; elements that are merely unsupported wrappers can be flattened, while explicitly dangerous or active elements are removed along with their contents. This distinction means ordinary words inside an unfamiliar formatting container may survive, but words placed inside a script or form will not. The tool also limits the amount of input and maximum traversal depth so an unexpectedly huge or pathological document does not consume unbounded resources. In a production pipeline, test representative malformed examples, examine output after any later transformations, and verify that downstream renderers do not reinterpret the sanitized markup in a more permissive context.

Frequently Asked Questions About Sanitize Html Online