HTML Minifier

HTML Minifier

Paste or type HTML into the box, load the Example, or Open a file up to 5 MB (you can also drag it onto the page). Then click Minify Code.

The result shows the original and minified sizes, plus the sizes after gzip and Brotli compression, which is what visitors actually download. Notes list everything that was changed or deliberately left alone. Copy the result, or Download it as name.min.html.

Minifying runs in your browser. Nothing you paste or open is uploaded.

Safe by default

With the two cautioned options off (they’re off unless you switch them on), browsers read the minified page exactly as they read the original. The layout, the text and the behaviour stay the same; only the bytes go.

The main reason this is harder than it sounds is whitespace. Between inline elements, a space is visible:

Open <strong>Monday</strong> to <strong>Friday</strong>.

A minifier that deletes every space between tags turns that into “OpenMondaytoFriday.” So this one shrinks each run of spaces and line breaks to a single space, and removes whitespace entirely only where browsers never display it, such as inside <head>.

What changes

Comments are removed, with three exceptions:

• Licence comments starting with <!--!, which many licences require you to keep.
• Server-side includes like <!--#include virtual="/footer.html" -->, which the server replaces with content.
• Conditional comments for old Internet Explorer.

Attributes are simplified.

• Quotes are removed where the value doesn’t need them.
• disabled="disabled" becomes disabled, since the attribute alone means the same.
• Default values are dropped, such as type="text/javascript" on scripts, type="text/css" on styles and method="get" on forms.
• Empty class and style attributes are dropped.

One default is deliberately kept: type="text" on inputs. A stylesheet rule like input[type="text"] only matches inputs that actually have the attribute, so removing it could change how a form looks.

The doctype is shortened to <!DOCTYPE html> only when the page already renders in standards mode. An old doctype that puts the browser into “quirks mode” is kept, with a note explaining why. Switching it would change how the browser calculates sizes and spacing, and the layout could shift.

Inline JavaScript loses spaces, line breaks and comments, using the same engine as the JS Minifier with every rewriting option off. Names and logic stay as written. This includes module scripts, event handler attributes like onclick, and JSON scripts such as JSON-LD structured data. If a script doesn’t parse, it’s left exactly as written, and a note names its line.

Inline CSS loses comments and spaces, and short forms are used where they mean the same: 0.5em becomes .5em, and #aabbcc becomes #abc. Spaces that carry meaning are kept:

• Inside strings and url().
• Around + and - in calc(). calc(100% - 10px) stops working without them.
• In selectors. .menu :hover, with a space, means “any hovered element inside .menu”, while .menu:hover means “.menu itself when hovered.”

What’s never touched

Some content depends on its exact formatting, so it’s left exactly as written, along with everything inside it:

• <pre> and <textarea>, where spaces and line breaks are part of the content
• <svg> and <math>, which follow their own rules
• PHP blocks and template tags, which a server or template engine still has to read

The two cautioned options

Both are off by default and come with a warning, because each can change something in specific cases. If you turn either one on, test the minified page on your site before replacing the original, and keep the original file.

Remove whitespace between block elements. This saves a few more bytes, but it isn’t always invisible. Menus are often built from list items styled as display: inline-block, and the gap between those items comes from the whitespace between the tags in the HTML. Remove it and the menu items move together.

Remove optional closing tags. HTML allows some closing tags to be left out, such as </li>, </p>, </td>, </tr> and </option>. Browsers build the same page either way. But XML parsers, some editors and some template engines expect every tag to be closed.

How much will it save?

The sizes after gzip and Brotli are the ones that matter, because nearly every server compresses HTML before sending it, and repeated whitespace compresses extremely well.

On real pages, the saving after compression is usually modest. On three documentation pages we tried, it was between 3% and 9%. Hand-indented templates with lots of comments save more; pages that are already lean save less.

Often larger wins:

• Compression on the server. Check it with the GZIP Compression Test.
• Smaller images. Use the Image Compressor.
• Leaner stylesheets and scripts. Use the CSS Minifier and JS Minifier.

FAQ

Will minifying break my page?

Not with the default settings: browsers read the result exactly as the original. The two cautioned options can change layouts or upset other tools in the cases described above, so test before using them.

Can I get the readable version back?

The HTML Formatter restores indentation and line breaks, but removed comments are gone for good. Keep your original file and minify a copy.

Does minifying HTML help SEO?

Only indirectly. A smaller page downloads a little faster, which helps page speed. But the difference after compression is usually small, and search engines don’t rank pages by HTML size.

Can I minify a WordPress or PHP template?

PHP blocks are left as written, so a template still works after minifying. For a live WordPress site, it’s usually easier to let a caching plugin minify the pages it generates.

Is my code uploaded anywhere?

No. Everything happens in your browser, and nothing you paste or open is stored.