How to Fix Unminified HTML on Your Website

Unminified HTML is a quiet tax on every request. Pretty printing, redundant whitespace, and inline comments that only matter to developers all ship to every visitor. Each page is larger than it needs to be, every render slightly slower, and every byte over the wire costs bandwidth you pay for and time users notice.

The fix is almost always a single config flag, once you know where to put it. This guide covers both the detection and the setup. For the sibling fixes, see render blocking CSS for stylesheet minification and slow JavaScript for script minification.

Before you dive in, the quick no code answer. Webflow and Framer both minify published HTML automatically, so if that is your stack you can skip most of this page. The one exception is custom HTML you have pasted into an embed block, which your builder does not rewrite, so run the Step 1 source check on those and tidy them by hand. For custom builds, read on.

Step 1: Detect whether your HTML is minified

Open any page on your site, right click, view source. Minified HTML looks like a single long line with no indentation and no development comments. Unminified HTML looks almost exactly like your template code. Look for four common signs:

• Leading whitespace and indentation before every tag
• Blank lines between sections
• HTML comments that describe sections rather than serve runtime purposes
• Framework specific comments like data binding hints that leaked into production

Our Website Optimizer flags unminified HTML automatically and reports the size difference between the current output and a minified version. For whole-site checks, our Heavy Asset Finder does the same scan across every page.

Step 2: Decide where to minify

There are three layers where HTML minification can happen. Pick one, not all three.

• Build time: for static sites and frameworks that pre-render HTML. Output is minified once and served as-is. Fastest at request time.
• Render time: for server rendered pages. The server minifies the response before sending it. Small CPU cost per request.
• Edge: for any site behind a CDN. Cloudflare, Fastly, and others can minify HTML at the edge, usually with a single toggle.

Build time is the cleanest choice when you can use it. Edge minification is the easiest to turn on for an existing site, but it cannot do framework aware optimizations that a proper build step can.

Step 3: Configure html-minifier-terser or your framework default

html-minifier-terser is the de facto tool for HTML minification. Most bundlers and frameworks wrap it. A reasonable baseline config keeps things safe.

{
  "collapseWhitespace": true,
  "removeComments": true,
  "removeRedundantAttributes": true,
  "removeScriptTypeAttributes": true,
  "removeStyleLinkTypeAttributes": true,
  "useShortDoctype": true,
  "minifyCSS": true,
  "minifyJS": true
}

For Next.js, HTML is minified in production builds automatically. For Astro, it is on by default. For WordPress, either use a caching plugin that ships minification or enable it at the edge. Check the generated output after changing the config because defaults vary between versions.

Step 4: Avoid whitespace and comment traps

Aggressive HTML minification can collapse whitespace that your layout actually needs. Two traps come up repeatedly:

• Inline element spacing: two adjacent spans separated by a space render with a visible gap. Collapse the space and they run together. The MDN white-space reference explains the rules.
• Preserved regions: content inside pre, textarea, and script must keep its whitespace. Every decent minifier handles this, but always check.

Conditional comments used by very old Internet Explorer versions should be left alone if you still support them. Most sites no longer do.

Step 5: Compress the minified output

Minification removes characters. Compression replaces repeated patterns with shorter codes. They compound, and you want both. See the web.dev guide on text compression for the underlying numbers.

Enable Brotli at your server if your runtime supports it, with gzip as a fallback. Most CDNs do this for you, but self hosted setups sometimes ship uncompressed HTML without realizing it. Check the Content-Encoding response header. If it says br or gzip, you are good. If it is missing, compression is not running.

With minification and compression both in place, your HTML transfer size should drop meaningfully on every page. Re-run the Website Optimizer to confirm the unminified HTML flag has cleared.