Format HTML in Notepad++ by routing the file or selected fragment through a browser-based normalizer that parses text/html, serializes body.innerHTML, and returns the canonicalized markup to a read-only textarea without plugins, uploads, or a live preview. Notepad++ is excellent for writing and editing HTML — syntax highlighting, bracket matching, multi-caret editing, and macros all work without configuration — but the editor does not ship with a built-in HTML formatter, so a pasted snippet of scraped or hand-rolled markup stays exactly as messy as it arrived. The cleanest path that avoids installing a plugin is to copy the fragment out of Notepad++, paste it into a browser-side HTML normalizer, let the parser repair and serialize it, and then copy the result back into the editor. This approach leans on the browser's forgiving text/html tokenizer and tree constructor rather than on a third-party beautifier, which means the output reflects what the browser would actually build if the markup were rendered, not what a regex-based formatter guesses is right. Try the HTML Cleaner to do this in your browser.
Why Notepad++ Alone Won't Format HTML
Notepad++ treats HTML as plain text. It highlights tags, closes brackets, and supports indentation guides, but it never rewrites your markup the way a true formatter would. The common workarounds all require installing something: the XML Tools plugin (with its Pretty Print command), Tidy2, JSTool, or a portable beautifier script bound to a Run menu entry. Each option adds an admin install, a version matrix to manage, and a per-project configuration step.
For readers on locked-down machines, shared workstations, or ephemeral VMs, plugin installs are not always possible. Others prefer to avoid editor extensions entirely. In those situations the editor can stay vanilla and the formatting can happen in the browser, where every modern engine already ships a fully compliant HTML parser. The browser-side route also avoids the maintenance question that follows every plugin install: will this still work after the next Notepad++ upgrade, after a Windows policy refresh, or after a portable copy moves to a new machine.
The Browser Parser Approach
The HTML Cleaner tool accepts any HTML fragment or full document, runs it through DOMParser in text/html mode, optionally strips Comment nodes from the parsed body, and serializes the result from body.innerHTML into a read-only textarea. Nothing is uploaded, the parsed markup is never inserted into the live page, and no scripts inside the fragment are executed during parsing. According to MDN's DOMParser reference, the resulting document has no browsing context and scripting is disabled, but the browser may still fetch resources referenced by iframe and img URLs while the parser builds its separate document. Avoid pasting markup that points at hosts whose traffic would itself be a leak.
Because the parser follows the WHATWG HTML Living Standard tree-construction rules, the output reflects canonical browser serialization rather than a regex pass. That distinction matters: a naive pretty printer can split the raw text content of pre, textarea, script, or style and silently change DOM meaning, while DOMParser preserves that text verbatim per the standard's raw-text rules. The result is what a browser would build, not what a beautifier guessed the author intended.
How to Format HTML in Notepad++ Through Your Browser
- In Notepad++, select the markup you want cleaned (or press Ctrl+A to take the whole file) and copy it with Ctrl+C.
- Open HTML Cleaner in a new browser tab and paste the fragment into the input area.
- Decide whether Comment nodes should be removed from the parsed body, then enable or disable that option accordingly.
- Trigger the normalize action; the tool runs the input through DOMParser in text/html mode and serializes body.innerHTML.
- Review the body-only text output and the reported comment-removal count in the read-only result area.
- Copy the complete result, switch back to Notepad++, replace the original selection, and save the file.
- Confirm whether the destination that will host the markup needs a destination-aware sanitizer before publishing, and route the cleaned output through that sanitizer if so.
What the Browser Normalizer Actually Changes
The browser's text/html parser is deliberately forgiving. It silently repairs many problems that would fail a strict XML parser, then serializes the recovered tree through body.innerHTML. The table below summarizes the most common transformations a reader pasting scraped markup into Notepad++ will see in the returned text.
| Input shape | What the parser does | Visible in output |
|---|---|---|
| <DIV CLASS=X> | Lowercases tag names, quotes attribute values, supplies a default value when missing | <div class="x"> |
| <table><tr><td>row</td></tr></table> | Inserts an implied tbody around the row group per the tree-construction rules | A wrapped tbody appears in the serialized text |
| <p>one<p>two | Closes the first p when the next one opens, then closes both at end of block | Two complete paragraphs in the output |
| <!-- comment --> | Kept when comment removal is off; removed from the parsed body when the option is on | Removal count is reported alongside the serialized text |
| <!doctype html><html><head><meta>...</head>... | Doctype, document shell, and head-only metadata fall outside body.innerHTML | Not present in the returned text |
| <script>...</script>, onerror=, javascript: URLs | Preserved verbatim; the parser does not run scripts and does not strip dangerous tokens | Still present in the output, intact |
This is the honest contract. The output is what the parser built, not a beautified or sanitized version of what the author typed.
Limits, Boundaries, and the Security Line
The tool enforces two explicit budgets. Raw input is rejected above 500,000 UTF-16 code units before parsing, and the serialized body is validated at or below 1,000,000 code units before being returned. Boundary values are accepted; values one unit above either cap fail with an explicit message. Nothing is sliced, sampled, partially serialized, or silently switched to a different cleanup policy. An empty body after parsing or comment removal is reported as a valid zero-length output, not an error.
Comment removal is the only optional deletion rule. The tool does not remove scripts, styles, iframes, forms, SVG, MathML, event-handler attributes, javascript: URLs, remote URLs, inline CSS, data attributes, IDs, classes, or unknown elements. It does not rewrite URL schemes, enforce a content policy, or apply an allowlist. It is explicitly not a security sanitizer. As MDN's innerHTML reference warns, copying parsed markup into another execution context can activate the preserved behavior there. Use a maintained, destination-aware sanitizer — DOMPurify for live DOM, an allowlist filter for a CMS, a Markdown converter for safe display — whenever untrusted HTML will be injected into a live page.
Normalization is also not a conventional pretty printer. DOMParser plus 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 the goal is a minified bundle, route the cleaned result through a minifier; if the goal is source-stable indentation inside Notepad++, use an XML-aware pretty printer on the local file instead.
When to Reach for a Real Sanitizer Instead
Reach for a destination-aware sanitizer whenever the markup will be injected into a live DOM, rendered inside a CMS rich-text field, embedded in an email template, or otherwise handed to a context where preserved scripts and event attributes become live. The browser parser can repair scraped fragments, but it cannot tell you whether the result is safe to publish. For readers who mostly want their Notepad++ source cleaned of indentation drift, missing tbody, and stray comments, the browser-side normalizer is the right size of tool. For readers who paste HTML from emails, scraped pages, or third-party feeds into anything that renders later, the cleaner step should sit between the normalizer and the destination, never replace it.
If the workflow also touches XML or JSON inside the same editor, a parallel browser-based formatter follows the same round-trip shape without plugins. The Format XML Data in Notepad++ Without a Plugin guide covers the same copy-paste-clean-paste pattern for well-formed XML, and the principles around budgets, body-only scoping, and the non-sanitizer boundary apply in exactly the same way.