HTML minifier

Removes HTML comments and whitespace between tags conservatively.

{{ t("sizeBefore") }}: {{ minifyHtml.beforeSize }}
{{ t("sizeAfter") }}: {{ minifyHtml.afterSize }}
{{ t("sizeReduction") }}: {{ minifyHtml.reduction }}

Overview

HTML is the most widely read language in the world — not by programmers, but by machines. Every browser, Google crawler, social media bot, and accessibility reader needs to parse HTML to understand what is being served. Tim Berners-Lee published the first HTML document in 1991, at CERN, with a structure of just a few elements: headings, paragraphs, links, and lists. It was a format for sharing scientific articles among physicists. Nobody imagined that thirty years later that same format would carry entire applications, 3D games in the browser, and interfaces more complex than 1990s desktop software.

HTML minification removes what the browser ignores: HTML comments, multiple spaces between tags, and line breaks that exist only for developer readability. The result is a modest reduction — typically 5% to 15% — compared to JavaScript minification, because HTML already has less unnecessary space than .js files full of comments and formatting. The biggest size savings in HTML come from server-side compression: gzip and brotli are extraordinarily effective on HTML because tags are repetitive and compression algorithms love repetition.

An important caveat: HTML with inline JavaScript or CSS is harder to minify safely. A minifier that does not distinguish between contexts can remove spaces inside script or style blocks and break the code. The standard recommendation is to externalize scripts and styles before minifying — and in modern projects with webpack or Vite, that already happens automatically as part of the build process. Manually minifying HTML makes the most sense in simple static projects, email templates, or CMS-generated pages without a build pipeline.

Technical deep dive

Semantic HTML and Google crawlability

  • Googlebot uses HTML to understand content hierarchy. The heading order (h1 → h2 → h3) signals the document structure. One h1 per page is the convention, and it should contain the primary keywords. Minification does not affect semantics — only whitespace.
  • Landmark elements like `<main>`, `<nav>`, `<header>`, `<footer>`, and `<article>` help both Google and screen readers navigate the document. They have no visual impact but do affect accessibility and structural SEO.
  • Structured data (schema.org via JSON-LD, microdata, or RDFa) embedded in the HTML lets Google display rich snippets in search results: star ratings, product prices, event dates. HTML minification that preserves attribute content does not interfere with this data.
  • The `alt` attribute on images is indexed by Google Images and read by screen readers. An `<img>` tag without `alt` is invisible to image searches and inaccessible to assistive technology users. No minifier removes attributes — and none should.
  • Open Graph (`og:title`, `og:description`, `og:image`) and Twitter Cards are meta tags in the `<head>` that control how the page appears when shared on social media. They live in the HTML and are read by preview bots. Minifying the `<head>` does not affect these tags.

Gzip and brotli outperform manual minification on HTML

  • Gzip compression typically reduces HTML to 70% to 80% of its original size — far more than the 5% to 15% of manual minification. This works because HTML is highly repetitive: the same tags (`<div>`, `<p>`, `<span>`) appear hundreds of times, and gzip's LZ77 algorithm exploits that.
  • Brotli (developed by Google, 2015) is 15% to 25% more efficient than gzip on HTML. It is supported by all modern browsers and by Nginx 1.11.5+, Apache with mod_brotli, and CDNs like Cloudflare and Fastly.
  • The optimal sequence is: minify the HTML first (remove whitespace and comments), then apply server-side compression. The two processes are complementary — minification removes bytes that compression would struggle to compact efficiently.
  • HTTP/2 Server Push and Resource Hints (`<link rel=preload>`) allow the server to send critical resources before the browser requests them. This reduces the render-blocking impact of CSS and JavaScript on the initial paint.
  • To verify the server is compressing correctly: `curl -H 'Accept-Encoding: br,gzip' -I https://your-site.com/` should show `Content-Encoding: br` (brotli) or `Content-Encoding: gzip` in the response headers.

Tool guide

  • What HTML is See earlier sections.

  • What the minifier does Removes HTML comments and whitespace between tags conservatively.

  • Why use it Shrink static HTML for simple deploys. Keep readable source in the repo; minified HTML is harder to debug.

Code Snippets

Before and after HTML minification
<!-- BEFORE -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- meta viewport -->
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Page</title>
  </head>
  <body>
    <!-- main content -->
    <main>
      <h1>Page Title</h1>
      <p>Paragraph content.</p>
    </main>
  </body>
</html>

<!-- AFTER -->
<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>My Page</title></head><body><main><h1>Page Title</h1><p>Paragraph content.</p></main></body></html>
Enable brotli compression in Nginx
# nginx.conf (requires ngx_brotli module)
http {
    # Enable brotli
    brotli on;
    brotli_comp_level 6;           # 0-11; 6 is the standard balance
    brotli_types
        text/html
        text/css
        text/javascript
        application/javascript
        application/json
        image/svg+xml;

    # Keep gzip as fallback for browsers without brotli support
    gzip on;
    gzip_types text/html text/css application/javascript;
    gzip_comp_level 6;

    # Cache pre-compressed files (if .br files exist on disk)
    brotli_static on;
    gzip_static on;
}

Sample

<div>
  <p> Olá </p>
</div>

FAQ

What is this tool for?

It runs fully in your browser: useful to validate, format, or convert data in everyday development.

Are my inputs sent to a server?

Processing happens locally with JavaScript. We do not store what you paste into the text areas.

Can I use this for real production data?

Use at your own risk. For secrets (passwords, tokens), prefer controlled environments and your company policies. And always review the generated contents. Never trust blindly things you see on the internet.