An HTML cleaner alternative built on DOMParser parses a fragment through the browser's text/html tokenizer, optionally removes comment nodes, and serializes only the parsed body as inert text. Unlike typical online beautifiers that reformat indentation or claim to sanitize, this approach deliberately does three things: it lets the browser's HTML parser do the structural repair, it displays the serialized result in a read-only textarea so nothing is ever injected into the live page, and it is explicit that no security boundary is being enforced. If you have ever pasted a fragment into a "cleaner" and wondered whether the round trip changed something you cared about, the appeal of a parser-driven alternative is that the changes you see are the changes the browser would make on its own. The tool never uploads the input to Lizely, never executes parsed scripts, never produces a live HTML preview, and never claims the output is safe to inject elsewhere. The trade-off is honesty: it preserves scripts, event handlers, iframe and img URLs, styles, and unknown elements exactly as parsed, because none of those fall within its single optional deletion rule.
What Sets a Browser-Based HTML Cleaner Alternative Apart
Most HTML cleaners you find in search results fall into three loose families: regex-driven formatters that re-indent without parsing, source-aware beautifiers that aim for pretty output, and sanitizers that try to remove dangerous nodes. The browser-parser approach is none of these. It uses the same text/html parser that builds every page you load, then asks that parser to give back its canonical view of the body. The point is not to produce the most readable output — it is to produce the output a browser would produce if it parsed your fragment today.
That matters for two reasons. First, it gives you a deterministic answer to questions like "what does my fragment actually look like to the browser?" and "did I forget to close a tag?" Second, it makes the limits obvious. The parser is forgiving by design, so malformed input is repaired rather than rejected with an XML-style error, and the serializer outputs body markup only, never the document shell or head-only metadata. If you want byte-identical, prettified, or sanitized output, this is the wrong layer — you want a different tool with a different promise.
For developers who specifically want a local alternative without an upload step, this category of tool is worth comparing against hosted formatters. The HTML Cleaner page documents exactly which promises it keeps and which it explicitly refuses.
Scope of the Cleaner: Body Markup, Comments, and Nothing Else
HTML Cleaner has a deliberately narrow contract. The raw input goes through DOMParser in text/html mode, the optional toggle decides whether Comment nodes are removed from the parsed body, and the result is serialized from body.innerHTML into a read-only textarea. That is the entire pipeline. There is no allowlist, no policy engine, no URL rewriter, no attribute stripper, and no script remover.
Because the contract is narrow, the table below is worth reading carefully. Every row describes a real behavior, not a marketing claim.
| Behavior | What HTML Cleaner Actually Does |
|---|---|
| Runs entirely in the browser | Yes — no upload to Lizely |
| Parses the input | DOMParser with text/html mode |
| Removes comment nodes | Optional, single toggle |
| Removes script or style blocks | No — preserved as parsed |
| Removes event-handler attributes (onclick, onerror) | No — preserved |
| Rewrites javascript: URLs | No — preserved |
| Removes iframe, img, form, SVG, MathML | No — preserved |
| Renders a live preview | No — read-only textarea only |
| Executes parsed scripts | No — DOMParser document has no browsing context |
| Downloads remote resources | Possible — iframe and img references may fetch |
| Re-indents or pretty-prints | No — canonical browser serialization only |
| Preserves doctype, head, title, meta | No — body-only output |
| Maximum raw input | 500,000 UTF-16 code units, checked before parsing |
| Maximum normalized output | 1,000,000 UTF-16 code units, checked before return |
| Suitable for untrusted HTML | No — use a destination-aware sanitizer |
The bottom row is the most important one. A result containing a script tag or an onerror attribute is dangerous if a downstream application injects it into a live page. The parser is disabled-script by construction, and the textarea is inert, but copying the output into innerHTML, a CMS body field, an email template, or any other execution context activates it there. MDN's innerHTML reference documents the same injection risk.
How to Normalize and Clean an HTML Fragment
Use the tool as a quick normalization and comment-removal step, not as a sanitizer. The flow below mirrors the verified operating steps on the tool page.
- Paste an HTML fragment or a complete document into the input area, then decide whether HTML comment nodes should be removed.
- Trigger normalization. The tool parses with DOMParser in text/html mode, removes Comment nodes if the toggle is on, and serializes body.innerHTML.
- Review the body-only text in the read-only output area, and read the comment-removal count the tool displays.
- Copy the complete result only after you have decided whether the destination also requires a real HTML sanitizer.
Two practical details are worth knowing. First, the input limit is checked before parsing, so an oversized paste is rejected up front rather than after a long parse. Second, editing the input or flipping the comment toggle clears the previous result, the comment count, any error, and the clipboard state — the tool uses a generation guard so a late clipboard permission from an earlier copy cannot restore stale status after an edit, retry, or unmount. If the browser denies the clipboard write, the complete output stays available in the read-only textarea for manual selection.
What the Browser Parser Repairs During Normalization
Because the tool leans on the browser's HTML parser, it inherits every repair rule the parser applies. The WHATWG HTML Living Standard defines text/html tokenization and tree construction, and the parser is deliberately forgiving. In practice you can expect the following kinds of changes when you round-trip a fragment:
- Element names get lowercased because HTML element names are case-insensitive in the parsed DOM.
- Attribute values get quoted by the serializer when the original markup omitted quotes, and certain attributes are normalized in form.
- Implied elements such as tbody are inserted inside tables that omitted them, because tree construction requires them.
- Some missing closing tags are repaired rather than reported as errors.
- Markup is rearranged under HTML tree-construction rules when the input order would otherwise violate the content model.
The serialization is intentionally scoped to body.innerHTML, so a complete input document may contain doctype, html, head, title, meta, link, style, and body sections, but the returned text contains only the parsed body's child markup. Doctype and the document shell are not copied. Head-only metadata is outside the output unless the parser's standard recovery rules move a particular token into the body. If the complete page shell must be preserved, a document-aware editor is the right tool.
Text inside pre, textarea, script, and style follows HTML parsing rules and is not reformatted by a custom lexical pass. That is by design: a naive formatter could accidentally split raw-text content or change DOM meaning. The tool reports parser API exceptions, a missing body output, or an invalid parser result, but it does not promise strict standards conformance and does not claim that recovered structure matches the author's original intention.
Hard Limits and Honest Trade-Offs
Three limits are worth planning around. Input may contain at most 500,000 UTF-16 code units, and normalized output may contain at most 1,000,000. The raw input limit is checked before parsing, and the complete body serialization is measured before a result is returned. Exact boundary values are accepted; boundary-plus-one values fail with explicit messages. Nothing is sliced, sampled, partially serialized, or silently switched to a different cleanup policy. An empty body after parsing or comment removal is a valid zero-length output.
DOMParser creates a separate document with scripting disabled, and the result lives only in a read-only textarea, but the browser may still download resources referenced by parsed iframe or img elements during parsing. Avoid pasting sensitive HTML containing remote resource URLs if those requests would disclose information to another host. MDN's DOMParser.parseFromString reference documents this behavior and the lack of a browsing context.
HTML normalization is not a conventional pretty printer. DOMParser and innerHTML produce canonical browser serialization but do not promise indentation, line wrapping, attribute sorting, source whitespace preservation, or stable byte-for-byte output across every browser version. If you need minified output, prettified output, or identical bytes across engines, those are different goals with different tools.
When HTML Cleaner Is the Wrong Tool
The tool fits a small, honest niche: see how a browser normalizes a fragment, remove comments from an otherwise unchanged parsed structure, or prepare body markup for manual review. It does not fit tasks where the reader's intent is something else.
- Standards validation. The forgiving parser repairs malformed markup instead of rejecting it, so a strict validator is what you want when conformance is the goal.
- Security sanitization. Active content is preserved, so a destination-aware sanitizer such as DOMPurify or a maintained server-side equivalent is the right layer for untrusted HTML.
- Full document preservation. Doctype, head, title, meta, link, and style at the document level are outside the output, so a document-aware editor is required when the page shell must round-trip.
- Pretty printing or minification. Canonical browser serialization is not the same as beautified or compact output; use a formatter or minifier for that.
- Cross-browser byte identity. Two browsers are not guaranteed to produce byte-identical output for the same input.
- Publish-time safety proof. Copying the output into innerHTML, a CMS, or an email template activates behavior in that context, so a separate sanitization pass is still needed.
For a related browser-first alternative with the same no-upload philosophy on a different input shape, see the text-to-html paragraphs API alternative walkthrough. Together they illustrate the same trade-off: a tool that does exactly one job in your browser, documents the boundary honestly, and refuses to claim guarantees it cannot keep.
If you're weighing options, How to Edit an HTML Page Online Without Software covers this in detail.