HTML Minifier

Compress HTML by dropping comments and redundant whitespace, without the markup leaving this tab.

Runs on your deviceDeveloperWorkingNo account needed

What this tool does

HTML Minifier walks your markup character by character instead of building a DOM, which is why a loose fragment works as readily as a complete document and why nothing it fails to recognise gets rewritten. Comments go, runs of whitespace between elements collapse to a single space, and the space beside a tag on its structural list — the block elements, plus br, iframe, video and canvas — is dropped entirely. The summary reports the UTF-8 size before and after with the percentage saved, measured on your own markup rather than quoted from an average — and measured here, in this browser tab, because the minifier is plain JavaScript on the page and the input is never uploaded.

Several things are deliberately left alone. The bodies of <pre> and <textarea> pass through byte for byte, so preformatted code keeps its indentation and a filled-in text box keeps its line breaks. Attribute values keep their spacing, their quoting and their case, so an alt text written across two lines stays as written, and the space in <img src=x /> is kept because removing it would join an unquoted value to the closing slash. Conditional comments beginning <!--[if and comments beginning <!--! survive even with comment removal switched on.

Also minify inline <style> and <script> hands those blocks to the same routines behind CSS Minifier and JavaScript Minifier. Stylesheets lose their comments and whitespace and #aabbcc colours shorten to #abc, with /*! licence blocks kept. Scripts lose comments and indentation only: nothing is renamed, no dead code is removed and statements are never joined onto one line, so code that relies on automatic semicolon insertion still runs. A <script> whose type attribute names something other than JavaScript — application/json, text/template, a Handlebars block — is recognised and copied out unchanged. Switch the option off and script and style bodies are not touched at all.

Two limits are worth knowing before you paste production markup in. The first is that this is a conservative minifier: optional closing tags stay, quotes are never stripped from attribute values, default and boolean attributes are not shortened, and nothing is reordered or deduplicated. It will therefore save less than a tool that rebuilds the document, and in exchange it has nothing to get wrong. The second is whitespace itself. Whether a space goes is settled by the tag name against a fixed list, never by your stylesheet, and that list counts br, iframe, video and canvas as structural alongside the true block elements. A menu whose list items are styled display:inline-block therefore loses the newline that was drawing the gap you see, and an iframe set in a line of prose ends up flush against the words either side. Look at the rendered page afterwards, or leave Collapse whitespace off and take the comment saving alone.

How to use it

  1. Paste the HTML. A full document with its doctype, or a fragment out of the middle of a template. The scanner does not require balanced tags, and it does not try to repair them either.
  2. Choose which passes run. Remove comments, Collapse whitespace, and Also minify inline <style> and <script> are all on by default. Turn one off and run again to see exactly what that pass was worth.
  3. Copy the output and read the saving. The minified markup appears in the output pane, with the UTF-8 size before and after — in bytes, or in KB once it passes a kilobyte — and the percentage the file shrank by.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Shrinking an HTML email before sending

Mail templates are generated with deep indentation and comment scaffolding, and Gmail clips a message once it passes roughly 102 KB. The Outlook conditional comments are kept while the rest goes.

Trimming a template on the way to production

Build comments and editor indentation help nobody who loads the page. This removes them without touching the classes and data attributes your CSS and scripts select on.

Fitting markup into a single-line field

A CMS setting, a JSON string or a data attribute cannot hold indented HTML. Collapsed markup comes back on one line, unless it carries a <pre>, a <textarea> or a script block, each of which keeps its own line breaks.

Seeing how much of a page is scaffolding

Page builders and component frameworks emit a lot of markup nobody renders. The before and after figures put a number on it.

Questions

Where does the minifying happen?
Inside the page you are reading, in JavaScript your browser has already loaded. The markup you paste is not transmitted, logged or stored, and the tool carries on working with the network disconnected.
Will minifying break my page?
It is built not to. Quoted attribute values, <pre> and <textarea> bodies and non-JavaScript <script> blocks all pass through unchanged, and no element is ever removed. What it can change visibly is spacing: wherever a gap was being drawn by whitespace rather than by CSS — between inline-block list items, or beside an iframe or video sitting in a line of text — collapsing that whitespace closes it.
Why does another minifier report a bigger saving?
Because it rewrites the document and this one does not. Optional closing tags, attribute quotes, default attribute values and boolean attribute values are where an aggressive minifier finds its extra few per cent, along with the risk of changing how a browser parses the result.
Does it compress the CSS and JavaScript inside the page?
Yes, while Also minify inline <style> and <script> is on. Stylesheets go through the CSS minifier; script blocks lose comments and indentation but keep every identifier and every statement break. Blocks with a non-JavaScript type are skipped.
Are all comments removed?
Only ordinary ones. A conditional comment starting <!--[if and a comment starting <!--! are both kept with Remove comments on, so a licence header or a client-specific block in an email template is not silently lost.
Should I minify HTML instead of enabling gzip?
Enable compression first — it does far more for what actually travels over the wire. Minifying earns its place where the raw bytes are what count: an email body, an inlined template, a field with a size cap.
Does it validate my markup?
No. It is a scanner, not a parser, so unbalanced tags, duplicate ids and misspelt element names are passed along rather than flagged. One case is worth knowing: with Remove comments on, a comment you never closed takes everything after it, because the scanner reads to the end of the input looking for the --> that ends it — which is how a browser reads that markup too.

Related tools