HTML Cleaner normalizes HTML fragments through the browser's built-in HTML parser and can optionally remove Comment nodes, with the result shown only in a read-only text area that never previews or executes the markup. For developers who write HTML in Notepad++ and want it formatted without installing the Tidy2, XML Tools, or JSMin plugins, this browser-based path runs the same parsing rules that real browsers use when they render a page. The browser HTML parser is deliberately forgiving: it lowercases element names, quotes unquoted attributes, inserts implied elements like <tbody>, repairs some missing closing tags, and rearranges markup according to HTML tree-construction rules. That means the output you copy is what a real browser would build in memory after parsing your Notepad++ file, not a strict XML-style validation result. Paste your code, choose whether comments should be stripped, normalize, then read the body-only text and the comment-removal count before deciding where to paste it next.
Why Notepad++ Users Look Beyond Built-in HTML Formatting
Notepad++ is a fast, lightweight source editor, but its out-of-the-box HTML formatting story is thin. The Plugins menu ships with XML Tools, JSMin, and historically Tidy2, and each of those brings friction. Tidy2 is the closest analogue to a real HTML beautifier, yet its installer lives on GitHub releases that have been unreliable to reach, and the plugin is widely reported to fail to install cleanly on 64-bit Notepad++ builds. JSMin compresses whitespace but does not pretty-print, so a hand-formatted page comes out as a single long line. XML Tools formats markup, but it parses input as XML and rejects the unclosed tags, missing quotes, and implied elements that HTML tolerates by design.
For developers who already keep a browser tab open for documentation, that combination of quirks is enough to look for a normalization step that runs in the browser, uses the same parser a deployed page would use, and never asks for a plugin update. HTML Cleaner is that step: paste your Notepad++ file, pick a single option, and read the result without leaving the browser. The same idea applies to other text formats, and the JSON case is covered separately in Format JSON Files in Notepad++: Plugins and Alternatives.
How the Browser HTML Parser Repairs Markup
Normalization in HTML Cleaner is performed by DOMParser in text/html mode, which is the same parser a browser uses when it fetches and renders a web page. That parser is forgiving on purpose, so it almost never throws a syntax error. Instead, it applies a fixed set of repair rules defined by the WHATWG HTML Living Standard. Knowing those rules in advance makes the formatted output predictable rather than surprising.
| Input Pattern | Parser Behavior During Normalization |
|---|---|
| Uppercase or mixed-case tag names (<DIV>, <Html>) | Lowercased to canonical HTML names |
| Unquoted attribute values (id=main) | Quoted in the serialized output |
| Attribute values with no quotes or odd spacing | Reformatted to canonical attribute quoting |
| Missing <tbody> inside a <table> | Implied <tbody> inserted by tree-construction rules |
| Missing closing tags in many flow-content positions | Repair attempted; recovered end tag inserted automatically |
| Tokens placed in the wrong section of the source | Rearranged into the canonical document tree |
These repairs are why the output rarely matches the original byte-for-byte. The tree-construction step explicitly normalizes case, attribute quoting, and the placement of stray tokens before serialization. MDN's DOMParser.parseFromString reference documents that this parser runs in a separate document with scripting disabled, which is exactly the inert environment HTML Cleaner relies on.
Format HTML Code with HTML Cleaner: A Notepad++ Workflow
The whole operation lives inside the HTML Cleaner page. Treat it as a small side trip from Notepad++ rather than a replacement editor: you paste, normalize, review the count of comments removed, and copy back into Notepad++ or paste into a separate destination. The three operating steps mirror the product contract:
- Paste an HTML fragment or document into the input area and decide whether Comment nodes should be removed. Leave the option off if you want comments preserved; turn it on if you want every HTML comment stripped before serialization.
- Normalize, then review the body-only text output and the comment-removal count without executing it. The textarea is read-only and never inserted into the visible page, so the markup cannot run scripts or render a preview there.
- Copy the complete result only after deciding whether the destination also requires a real HTML sanitizer. If you plan to inject the output into innerHTML, a CMS, or an email template, run it through a maintained sanitizer configured for that destination first.
Editing the input or flipping the comment option immediately clears the previous result, error, statistics, copy status, and copy timer. Clipboard completion is guarded by a generation number and a mounted-state check, so a late permission response from an older copy attempt cannot restore stale status after you edit, retry, or navigate away. If the clipboard request is denied, the full normalized text remains visible for manual selection.
What HTML Cleaner Keeps, Changes, and Drops
The output is scoped deliberately. Serialization reads document.body.innerHTML, which means the returned text contains only the parsed body's child markup. Doctype, <html>, <head>, <title>, <meta>, <link>, and <style> are all outside that scope. Head-only metadata is dropped unless the parser's recovery rules happen to move a particular token into the body during tree construction. If your Notepad++ file is a complete document with a doctype and head section, the shell is intentionally not copied, so open the result in a document-aware editor when the full page must be preserved.
| Construct | Treated As |
|---|---|
| Comment nodes (<!-- ... -->) | Removed when the option is on; otherwise preserved |
| <script>, <style>, <iframe>, <form>, <svg>, <math> | Preserved verbatim |
| Event-handler attributes (onclick, onerror, etc.) | Preserved verbatim |
| javascript: URLs and remote URLs | Preserved verbatim |
| Inline CSS, data-* attributes, IDs, classes | Preserved verbatim |
| Doctype, <html>, <head>, <title>, <meta>, <link> | Out of scope; not copied into the output |
That distinction matters for security. A result that still contains a <script> tag or an onerror attribute is dangerous if another application later injects it into a live page. The tool never rewrites URL schemes, enforces a content policy, or applies an allowlist. As MDN's Element.innerHTML reference warns, fragment serialization does not sanitize, and copying it into another execution context can activate behavior there.
Limits, Sizes, and the Security Boundary
Two hard size caps guard the pipeline. Raw input may contain at most 500,000 UTF-16 code units; the limit is checked before parsing, so empty input and over-length input are rejected with explicit messages rather than silently truncated. Normalized output may contain at most 1,000,000 code units, measured against the complete body serialization before the result is returned. Exact boundary values are accepted; boundary-plus-one values fail. Nothing is sliced, sampled, partially serialized, or silently switched to a different cleanup policy. An empty body after parsing or after comment removal is a valid zero-length output.
HTML Cleaner is a formatting aid, not a security sanitizer. The browser parser runs in a separate document with scripting disabled, and the serialized result stays inside a read-only textarea, so scripts cannot execute inside the tool itself. However, browsers may still download resources referenced by parsed <iframe> and <img> elements while DOMParser builds its separate document, so avoid pasting sensitive HTML containing remote resource URLs if those requests would disclose information to another host. For untrusted input that will eventually be injected into a live page, use a maintained sanitizer configured for the destination context after you have finished formatting.
Indentation, line wrapping, attribute sorting, and byte-for-byte stability across browser versions are also explicitly out of scope. DOMParser and innerHTML produce canonical browser serialization but do not promise pretty-printing, and text inside <pre>, <textarea>, <script>, and <style> follows HTML parsing rules rather than a custom lexical pass, a deliberate choice to keep raw-text content intact. Use HTML Cleaner when you want to see how a browser will normalize a fragment, strip comments from otherwise unchanged parsed structure, or prepare body markup for manual review; do not use it to validate standards conformance, secure user input, preserve a full document, beautify indentation, minify source, or prove that copied output is safe to publish.
Related reading: How to Edit HTML in a Browser Using a Sandboxed Preview.