HTML Cleaner normalizes an HTML fragment by running the input through the browser's built-in DOMParser in text/html mode, then serializing only the parsed document body's innerHTML into a read-only textarea, with the only optional deletion being HTML comment nodes. That single definition describes the entire tool: paste markup, optionally enable comment removal, and read the canonicalized body text back out without previewing or executing the result. Parsing happens inside a detached DOMParser document, so embedded scripts remain inert throughout the cleaning process. Inputs larger than 500,000 UTF-16 code units are rejected before parsing, and a normalized body larger than 1,000,000 code units fails with an explicit error message, so there is no silent truncation. Use this workflow when you need to see how a real browser would repair a fragment, strip development-only comments, or generate stable body markup for manual review before it is hand-edited or pasted into a separate environment.
What "Cleaning" HTML Actually Means in a Browser
The phrase "clean HTML text" covers several distinct jobs, and the tool you reach for depends on which one is on your desk. Two readers who both search for this query may want completely different things: one wants to repair copy-pasted markup from a Word document, another wants to remove <!-- TODO --> comments before exporting a snippet, and a third is trying to make pasted email HTML safe for a CMS. A browser-based normalizer handles the first two cleanly but explicitly does not handle the third. Before opening the tool, it is worth being honest about which category of cleaning you actually need.
Two meanings worth keeping separate:
- Normalize: run the markup through a parser and apply the same tree-construction rules every browser applies. Element names get lowercased, attributes get quoted, missing close tags get repaired, and implied elements such as tbody get inserted. The output is canonical browser serialization.
- Sanitize: strip or rewrite dangerous constructs such as script, event-handler attributes, javascript: URLs, and iframes. This is a security job with a different threat model and requires an allowlist-aware library configured for the destination context.
HTML Cleaner is a normalizer with one optional deletion rule. The product description calls it "a browser normalization and formatting aid, not a security sanitizer." That distinction is the single most important fact to keep in front of you when working with the tool.
Where HTML Cleaner Fits in a Normalization Workflow
Reach for HTML Cleaner when you want a fragment viewed through the same lens a browser uses. A few concrete scenarios fit the tool's scope:
- A fragment pulled from a CMS export, an email template, or a third-party API, where you want to see what the browser tree looks like before you touch it.
- A test fixture that needs stable canonical serialization to compare against, instead of comparing raw, whitespace-sensitive source.
- A snippet full of debug and TODO comments that needs a clean body-only copy for documentation or a static-site generator.
- A debugging session for an HTML parser bug where you want the recovered tree a real browser produces, not the raw source.
These are the cases the tool is designed for. The product contract lists them explicitly: "Use this tool when you want to see how a browser normalizes a fragment, remove comments from otherwise unchanged parsed structure, or prepare body markup for manual review." Anything outside that scope, including sanitization, full-document preservation, validation, and beautification, is the wrong job for this tool.
Cleaning an HTML Fragment
- Open the tool. The page renders an input area on the left, a read-only output area on the right, and a single toggle for comment removal.
- Paste your fragment into the input area. A full HTML document with <!DOCTYPE html>, <html>, <head>, and <body> is accepted, but only the parsed body's children appear in the output. Up to 500,000 UTF-16 code units are accepted before parsing; anything larger is rejected with an explicit message.
- Decide whether comment nodes should be removed. The toggle controls the only optional deletion in the pipeline. When enabled, the tool walks the parsed body and any nested template DocumentFragments and removes every Comment node before serialization. When disabled, comments remain in the output as the browser parsed them.
- Trigger normalization. The tool parses the input with DOMParser in text/html mode, validates that a body exists, applies the optional comment walk, and serializes body.innerHTML into the read-only output area. There is no live HTML preview and no script execution.
- Review the body-only output and the comment-removal count. Read the result as inert text. If a parser API exception occurs, the body is missing, or the result fails the 1,000,000-code-unit bound, the tool reports a specific error rather than slicing or partially serializing.
- Copy the complete result only after deciding whether the destination also requires a real HTML sanitizer. Pasting the normalized body into innerHTML, a CMS field, an email template, or any execution context can reactivate scripts, event handlers, javascript: URLs, and embedded iframes.
What the Browser Parser Will Quietly Repair
The HTML text/html parser is intentionally forgiving. Where a strict XML parser would reject the input, the WHATWG parser follows tree-construction rules and emits a recovered tree. This is helpful when you want to see what a real browser would build, and it is also the reason malformed HTML produces output instead of an error.
Concrete repairs you should expect:
- Element names are lowercased. <DIV>, <Span>, and <P> become <div>, <span>, and <p> in the output.
- Attribute values are quoted. <a href=foo> becomes <a href="foo">.
- Missing close tags are repaired. <li>one<li>two becomes two separate list items, not one element with a stray child.
- Implied elements are inserted. A <tr> placed directly inside a <table> will gain a wrapping <tbody> in the output, even if the source never had one.
- Text inside <pre>, <textarea>, <script>, and <style> is preserved literally according to HTML parsing rules. The tool deliberately does not run a custom lexical pass over raw-text content, which avoids a naive formatter splitting raw text or changing DOM meaning.
The takeaway: what comes out is the browser's view of the input, not the author's original source.
Input Limits and Output Scope
Two hard limits govern what the tool accepts and emits:
| Boundary | Value | Behavior at the boundary |
|---|---|---|
| Raw input | 500,000 UTF-16 code units | Exactly 500,000 accepted; 500,001 rejected with an explicit message before parsing. |
| Normalized output | 1,000,000 code units | Exactly 1,000,000 accepted; 1,000,001 rejected with an explicit message before return. |
These limits are checked at fixed points in the pipeline, with raw input length measured before parsing and full body serialization length measured before the result is exposed. Neither input nor output is sliced, sampled, partially serialized, or silently downgraded. An empty body after parsing or comment removal is a valid zero-length output; that is not a failure.
Two scopes are intentionally outside the result:
- The document shell. Doctype, <html>, <head>, <title>, <meta>, <link>, and <style> are not part of body.innerHTML and do not appear. Use a document-aware editor when the complete page shell must be preserved.
- Head-only metadata. Tags placed in <head> stay there unless the HTML parser's standard recovery rules move a particular token into the body. Do not rely on the tool to reflect head edits back to you.
When to Reach for a Real Sanitizer Instead
The product contract is explicit: scripts, event attributes, URLs, iframes, styles, and other active markup are preserved. HTML Cleaner keeps scripts, inline event handlers like onerror, javascript: URLs, iframes, inline styles, and unknown elements. It does not rewrite URL schemes, enforce a content policy, or apply an allowlist. The result is inert while it sits in the textarea, but copying that result into innerHTML, a CMS, an email template, or another execution context can reactivate behavior.
Jobs HTML Cleaner will look like it does but actually does not:
- Cleaning pasted output from a rich-text editor before saving it as user content. Use a destination-aware sanitizer.
- Stripping onclick from user-submitted HTML. Use a sanitizer with an explicit attribute allowlist.
- Removing iframe or script from email HTML before forwarding. Use a sanitizer configured for the email client.
- Defending against pasted XSS payloads. A sanitizer is the only tool that helps here.
A practical pattern is to use HTML Cleaner first to inspect what the browser sees, then run the inspected body through a maintained sanitizer before publishing. The two tools do different jobs and are not interchangeable. For background on the security boundary, the MDN reference for DOMParser.parseFromString documents that scripting is disabled during parsing but resources referenced by iframe and img elements may still be requested. The MDN reference for Element.innerHTML covers fragment serialization and the injection risks of writing parsed markup into a live document.
Verifying the Output Against the Spec
Because HTML normalization is browser-defined rather than tool-defined, two reasonable checks before you trust the output:
- Cross-check with the WHATWG HTML Living Standard. The parser's tree-construction rules, including tokenization, implied elements, and attribute serialization, are defined there. If the output surprises you, the parser is almost always doing what the spec requires.
- Confirm body scope. If you pasted a full document and the doctype or head is missing, that is by design: the tool returns body.innerHTML only. A document-aware editor is the right next step if you need the shell preserved.
Two things the tool does not promise:
- Indentation, line wrapping, attribute sorting, or stable byte-for-byte output across browser versions. Different browser versions may serialize the same parsed tree differently. If you need byte stability, run a separate deterministic formatter on the result.
- Source whitespace preservation inside pre, textarea, script, and style. Those follow HTML parsing rules and are not touched by a custom lexical pass, which avoids a naive formatter accidentally splitting raw-text content or changing DOM meaning.
For routine review or test-fixture work, the canonical browser serialization from HTML Cleaner is enough. To compare the cleaned output against the original side by side, run them through a browser-based text diff checker that highlights added, removed, and unchanged regions in your browser. For byte-stable output, validation, or security-critical publishing, route the result through a tool built for that specific job.