Free HTML Minifier & Beautifier Online
Minify HTML to reduce page size or beautify it for easy reading. Preserves inline CSS and JS, handles void elements, and shows size savings. 100% client-side — your code stays private.
What does an HTML beautifier do? An HTML beautifier re-lays-out markup without changing it: it puts each tag on its own line and indents every line by how deeply it is nested, so the structure of the document becomes visible. Minifying is the same idea in reverse — comments are dropped and every run of whitespace collapses to a single space or disappears — which produces a smaller file that renders identically in the browser.
How to Use the HTML Minifier and Beautifier
- Paste your HTML — Drop in a full page, a fragment or a single element. Processing starts on the first keystroke, so there is nothing to submit — the Process button just re-runs it after you change an option.
- Pick minify or beautify — Beautify expands the markup for reading and debugging; Minify strips it down for shipping. The indent selector only affects beautify, and offers 2 spaces, 4 spaces or a tab character.
-
Set the minify options — Remove Comments deletes every
<!-- … -->block, including conditional comments. Remove Optional Attributes stripstype="text/javascript"andtype="text/css", which HTML5 treats as defaults. - Read the savings badge — The green badge next to the buttons shows how many characters were removed and the percentage. A red badge means the output grew, which is what beautifying is supposed to do.
-
Check the output before shipping it — Minification here is whitespace-aggressive and not aware of
<pre>or of significant spaces between inline elements — scan the result, or use beautify to compare structure, before replacing a production file. -
Copy or download — Copy puts the output on the clipboard; Download saves it as
formatted.htmlusing a blob URL, so no upload takes place.
How the Formatter Works
Both modes are hand-written scanners that walk the markup character by character rather than building a DOM. That matters in practice: nothing is corrected, reordered or re-encoded, so the text you get back contains exactly the tags and attributes you put in. It also means the tool is happy to format a template fragment full of {{ placeholders }} or server-side tags that a real HTML parser would reject or rewrite.
Beautify
The beautifier first tokenises the input into four kinds of thing — comments, the doctype, tags, and the text between tags. It then emits one token per line, prefixed by the current indent. An opening tag is printed and the depth increases; a closing tag decreases the depth first and then prints, so the pair line up in the same column. Void elements and self-closing tags print without changing the depth at all, which is why <br> and <img> do not shift everything below them to the right. Text nodes are trimmed and placed on their own line, and runs of three or more blank lines collapse to one.
The thirteen elements treated as void are the ones HTML5 defines that way: area, base, br, col, embed, hr, img, input, link, meta, source, track and wbr. Because the depth counter reacts only to literal tags, tags that HTML allows you to leave unclosed — a <li> or a <p> with no end tag — keep the depth open, and the indentation drifts steadily to the right. Closing those tags explicitly fixes both the output and, usually, whatever was confusing about the markup in the first place.
Minify
The minifier makes a single pass, and its first job is to notice <script> and <style>. Everything between those opening and closing tags is copied through untouched, so JavaScript that depends on line breaks and CSS that you have already minified elsewhere both survive intact. Only the opening tag itself is compacted. Outside those regions the rules are simple: comments disappear if the option is on, whitespace inside a tag collapses so attributes are separated by exactly one space, and any run of whitespace in the text becomes a single space — or nothing at all when the next character is <.
That last rule is the one to watch. Dropping the space before a tag turns Hello <b>world</b> into Hello<b>world</b>, and browsers render inline elements exactly as written, so words can end up joined. Whitespace inside <pre> and <textarea> is collapsed for the same reason, which visibly changes those elements. Minify content you control and check the result; for a production build pipeline, a parser-based minifier that understands these cases is the safer choice.
The size badge
The saving is the difference in string length between what you pasted and what came back, shown as a count and a percentage. For ordinary ASCII markup a character is a byte, so the figure is a fair estimate of the file-size change. It is measured before compression, though, and gzip or Brotli already handle repeated whitespace extremely well — a page that minifies 18% smaller on disk often gains only a few percent over the wire. Minifying HTML is worth doing, but the real wins on page weight are almost always images, fonts and JavaScript.
What Minify Changes and What It Leaves Alone
| Input | Result |
|---|---|
| Line breaks and indentation between tags | Removed |
| Multiple spaces inside a text run | Collapsed to one |
Whitespace immediately before a < | Removed entirely |
| Extra whitespace between attributes | Collapsed to one space |
<!-- comments --> | Removed when the option is checked |
type="text/javascript" and type="text/css" | Removed with Remove Optional Attributes |
Content of <script> and <style> | Copied through byte for byte |
| Attribute names, values and quoting | Left as written, apart from internal whitespace |
| Tag names, case and ordering | Never altered |
Entities such as & and | Never decoded or re-encoded |
Frequently Asked Questions
No. The scanner detects <script> and <style> and copies everything up to the matching closing tag verbatim, so line breaks inside your JavaScript survive and nothing is re-indented. Only the opening tag is compacted. If you want the CSS or JS itself made smaller, run it through the CSS Minifier or JS Minifier first and paste the result back.
In this tool, exactly two: type="text/javascript" on a script tag and type="text/css" on a style tag. HTML5 treats both as the default, so removing them changes nothing and saves a few bytes per tag. No other attribute is touched — class, id, empty attributes and duplicate values all come through exactly as you wrote them.
The formatting itself is entirely local — the scanner runs in JavaScript in your tab and no request carries your markup. Be aware of one thing though: your input and the option settings are also written into the page URL so a result can be bookmarked or reloaded. That stays in your address bar, but do not share the link if the markup contains anything you would not want to hand over.
Because whitespace that sits immediately before a < is deleted rather than collapsed. Browsers treat a single space between two inline elements as meaningful, so one <b>two</b> becoming one<b>two</b> visibly joins the words. Where that matters, put the space inside the element, use , or leave that section unminified.
No, and this is the tool's main limitation. Only <script> and <style> get verbatim treatment; a <pre> block or a <textarea> with pre-filled content is whitespace-collapsed like any other text, so code samples lose their formatting. Beautify those files instead, or minify around the block by hand.
The depth counter follows literal tags, so an opening tag with no matching close never gives its indent level back. HTML lets you omit end tags on <li>, <p>, <td> and others, and a real browser parser infers them — this formatter does not. Close them explicitly and the indentation lines up. A stray < in text or in an inline script comparison such as i<10 can cause the same drift, because the scanner reads it as the start of a tag.
Compression does the heavy lifting. Repeated indentation is extremely compressible, so a page that shrinks 15–20% when minified may only be a few percent smaller after gzip or Brotli. Minifying is still worth having in a build step, and it is genuinely useful for inlined email HTML or a data URI where no compression layer exists. It is not where you find a slow page's real weight.
Usually yes. Because nothing is parsed into a DOM, constructs like {{ value }}, <%= x %> and framework attributes pass through as ordinary text or as tags. The exception is any construct containing a bare < or > inside what the scanner reads as a tag, which will be mis-split. Check the output against the input before overwriting the file.
Use Cases
Reading a Page You Did Not Write
Paste the View Source output of a live page and beautify it to see the nesting. It is the quickest way to work out which wrapper is applying a layout, or where a third-party script injected its markup.
Cleaning Up Pasted CMS Markup
WYSIWYG editors emit long single-line blocks with inline styles. Beautify the block before editing it by hand so you can see where a stray div actually closes instead of scrolling sideways through one enormous line.
Making a Diff Readable
Two minified files produce a one-line diff that says nothing. Beautify both with the same indent setting, then compare them in Code Diff to see which attribute or element actually changed.
Shrinking an Email or Embedded Template
HTML email and markup stored in a database field are served without gzip, so removing whitespace is a genuine size win. Minify the template, check the inline elements still have their spaces, and paste it back.
Finding an Unclosed Tag
Run beautify and follow the indentation down the page. The line where every following element steps one level right and never comes back is the element you forgot to close.