HTML Minifier Next

Your web page optimization precision tool: HTML Minifier Next (HMN) is a super-configurable, well-tested, JavaScript-based HTML minifier able to also handle in-document CSS, JavaScript, and SVG minification.

The project was based on HTML Minifier Terser (HMT), which in turn had been based on Juriy “kangax” Zaytsev’s HTML Minifier (HM). HMN is the official successor to HTML Minifier: It’s maintained, easier to use, offers new features, and has been optimized for speed. Note that HMN is largely compatible with HM and HMT but has evolved—find migration guidance in the changelog.

Installation

HTML Minifier Next is ESM-only and requires Node.js ≥22.

For use as a command-line app, use npx:

npx html-minifier-next --help

(For immediate, zero-config use in the current folder: npx html-minifier-next --zero)

For programmatic use, install as a development dependency:

npm i -D html-minifier-next

General usage

CLI

Use npx html-minifier-next --help to check all available options:

Configuration file

You can use a configuration file to specify options. The file can be either in JSON format or a JavaScript module that exports the configuration object:

JSON configuration example:

{
  "collapseWhitespace": true,
  "removeComments": true,
  "fileExt": "html,php",
  "ignoreDir": "libs,vendor"
}

For editor support (validation, autocomplete, and inline documentation) in JSON configuration files, reference the JSON Schema that ships with the package:

{
  "$schema": "https://raw.githubusercontent.com/j9t/html-minifier-next/main/html-minifier-next.schema.json",
  "collapseWhitespace": true,
  "removeComments": true
}

(If HMN is installed locally, you can also use the path ./node_modules/html-minifier-next/html-minifier-next.schema.json instead of the URL.)

JavaScript module configuration example (requires "type": "module" in the project’s package.json, or use a .mjs extension):

export default {
  collapseWhitespace: true,
  removeComments: true,
  fileExt: "html,php",
  ignoreDir: ["libs", "vendor"]
};

Node.js

import { minify } from 'html-minifier-next';

const result = await minify('<p title="example" id="moo">foo</p>', {
  removeAttributeQuotes: true,
  removeOptionalTags: true
});
console.log(result); // “<p title=example id=moo>foo”

See the original blog post for details of how it works, descriptions of most options, testing results, and conclusions.

Presets

HTML Minifier Next provides presets for common use cases. Presets are pre-configured option sets that can be used as a starting point:

• conservative: Basic minification with whitespace collapsing, comment removal, and removal of select attributes.
• comprehensive: More advanced minification for better file size reduction, including relevant conservative options plus attribute quote removal, optional tag removal, and more.

To review the specific options set, presets.js lists them in an accessible manner.

Using presets:

# Via CLI flag
npx html-minifier-next --preset conservative input.html

# Via config file
npx html-minifier-next --config-file=html-minifier-next.json input.html
# where html-minifier-next.json contains: { "preset": "conservative" }

# Override preset options
npx html-minifier-next --preset conservative --remove-empty-attributes input.html

Priority order: Presets are applied first, then config file options, then CLI flags. This allows you to start with a preset and customize as needed.

Options quick reference

Most of the options are disabled by default. Experiment and find what works best for you and your project.

Options can be used in config files (camelCase) or via CLI flags (kebab-case with -- prefix). Boolean options generally support both --option-name to enable and --no-option-name to disable, so you can override a preset or config file from the command line. (Exception: Options whose name already starts with no-, such as noNewlinesBeforeTagClose, only expose the --no-… CLI flag.)

API-only options

A few options take functions and are therefore only available programmatically, not via CLI flags or config files:

Sorting attributes and style classes

Minifier options like sortAttributes and sortClassNames won’t impact the plain-text size of the output. However, using these options for more consistent ordering improves the compression ratio for Gzip and Brotli used over HTTP.

CSS minification

When minifyCSS is set to true, HTML Minifier Next uses Lightning CSS to minify CSS in style elements and attributes. Lightning CSS provides excellent minification by default.

You can pass Lightning CSS configuration options by providing an object:

const result = await minify(html, {
  minifyCSS: {
    targets: {
      // Browser targets for vendor prefix handling
      chrome: 95,
      firefox: 90,
      safari: 14
    },
    unusedSymbols: ['unused-class', 'old-animation']
  }
});

Available Lightning CSS options when passed as an object:

• targets: Browser targets for vendor prefix optimization (e.g., { chrome: 95, firefox: 90 }).
• unusedSymbols: Array of class names, IDs, keyframe names, and CSS variables to remove.
• errorRecovery: Boolean to skip invalid rules instead of throwing errors. This is disabled by default in Lightning CSS, but enabled in HMN when the continueOnMinifyError option is set to true (the default). Explicitly setting errorRecovery in minifyCSS options will override this automatic behavior.
• sourceMap: Boolean to generate source maps.

For advanced usage, you can also pass a function:

const result = await minify(html, {
  minifyCSS: function(text, type) {
    // `text`: CSS string to minify
    // `type`: `inline` for style attributes, `media` for media queries, `undefined` for `<style>` elements
    return yourCustomMinifier(text);
  }
});

JavaScript minification

When minifyJS is set to true, HTML Minifier Next uses Terser by default to minify JavaScript in <script> elements and event attributes.

You can choose between different JS minifiers using the engine field:

const result = await minify(html, {
  minifyJS: {
    engine: 'swc', // Use SWC for faster minification
    // SWC-specific options here
  }
});

Available engines:

• terser (default): The standard JavaScript minifier with excellent compression
• swc: Rust-based minifier that’s significantly faster than Terser (requires separate installation)

To use SWC, install it as a development dependency:

npm i -D @swc/core

Important: Inline event handlers (e.g., onclick="return false") always use Terser regardless of the engine setting, as SWC doesn’t support bare return statements. This is handled automatically—you don’t need to do anything special.

You can pass engine-specific configuration options:

// Using Terser with custom options
const result = await minify(html, {
  minifyJS: {
    compress: {
      drop_console: true  // Remove console.log statements
    }
  }
});

// Using SWC for faster minification
const result = await minify(html, {
  minifyJS: {
    engine: 'swc'
  }
});

For advanced usage, you can also pass a function:

const result = await minify(html, {
  minifyJS: function(text, inline) {
    // `text`: JavaScript string to minify
    // `inline`: `true` for event handlers (e.g., `onclick`), `false` for `<script>` elements
    return yourCustomMinifier(text);
  }
});

SVG minification

When minifySVG is set to true, HTML Minifier Next uses SVGO to optimize inline SVG elements. Complete <svg> subtrees are extracted and processed as a block, enabling deep structural optimization:

const result = await minify(html, {
  minifySVG: true // Enable with SVGO defaults
});

You can pass custom SVGO options:

const result = await minify(html, {
  minifySVG: {
    plugins: [{
      name: 'preset-default',
      params: {
        overrides: {
          convertShapeToPath: false // Keep original shapes
        }
      }
    }]
  }
});

Important:

• SVG minification only applies within <svg> elements
• Case sensitivity and self-closing slashes are automatically preserved in SVG (regardless of global settings)
• For maximum compression, use minifySVG together with collapseWhitespace and other options

CSS, JavaScript, and SVG cache configuration

HTML Minifier Next uses in-memory caches to improve performance when processing multiple files or repeated content. The cache sizes can be configured for optimal performance based on your use case:

const result = await minify(html, {
  minifyCSS: true,
  minifyJS: true,
  minifySVG: true,
  // Configure cache sizes (in number of entries)
  cacheCSS: 750,  // CSS cache size, default: 500
  cacheJS: 250,   // JS cache size, default: 500
  cacheSVG: 100   // SVG cache size, default: 500
});

Via CLI flags:

npx html-minifier-next --minify-css --cache-css 750 --minify-js --cache-js 250 --minify-svg --cache-svg 100 input.html

Via environment variables:

export HMN_CACHE_CSS=750
export HMN_CACHE_JS=250
export HMN_CACHE_SVG=100
npx html-minifier-next --minify-css --minify-js --minify-svg input.html

Configuration file:

{
  "minifyCSS": true,
  "cacheCSS": 750,
  "minifyJS": true,
  "cacheJS": 250,
  "minifySVG": true,
  "cacheSVG": 100
}

When to adjust cache sizes:

• Single file processing: Default 500 is sufficient
• Batch processing: Increase to 1000 or higher for better cache hit rates
• Memory-constrained environments: Cache sizes can be lowered, though the savings are usually negligible—entries are typically kilobyte-scale, so even full caches only hold a few megabytes
• Hundreds/thousands of files: Increase to 1000–2000 for optimal performance

Important:

• Cache locking: Caches are created on the first minify() call and persist for the process lifetime. Cache sizes are locked after first initialization—subsequent calls reuse the same caches even if different cacheCSS, cacheJS, or cacheSVG options are provided. The first call’s options determine the cache sizes.
• Zero values: Explicit 0 values are coerced to 1 (minimum functional cache size) to avoid immediate eviction. To keep the cache footprint as small as possible, use a small number like 10 or 50 instead of 0.
• Entry size cap: Individual CSS, JavaScript, or SVG blocks larger than 1 MB are minified normally but not stored in the cache—this bounds worst-case cache memory without affecting realistically sized inline content. (This cutoff is fixed and not configurable.)

The caches persist across multiple minify() calls, making them particularly effective when processing many files in a batch operation.

Inspecting cache effectiveness:

Use getCacheStats() to see hit/miss counts and current occupancy for each cache:

import { minify, getCacheStats } from 'html-minifier-next';

// After minifying pages that share templated CSS/JS…
for (const html of pages) {
  await minify(html, { minifyCSS: true, minifyJS: true });
}

console.log(getCacheStats());
// {
//   css: { gets: 392, hits: 298, size: 94, limit: 500 },
//   js: { gets: 1196, hits: 1192, size: 4, limit: 500 },
//   svg: { gets: 0, hits: 0, size: 0, limit: 500 }
// }

A cache that was never exercised (e.g., minifySVG disabled, or minify() not yet called) reports all-zero stats.

The CLI’s --verbose and --dry modes print the same information to STDERR at the end of a run, omitting caches that were never touched.

Minification comparison

Please see the Minifier Benchmarks project for details on how HTML Minifier Next compares to other minifiers.

Examples

CLI

Sample command line:

npx html-minifier-next --collapse-whitespace --remove-comments --minify-js --input-dir=. --output-dir=example

npx html-minifier-next --input-dir=test --preset comprehensive --output-dir example

Process specific files and directories:

# Process default extensions (html, htm, shtml, shtm)
npx html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist

# Process only specific extensions
npx html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --file-ext=html,php

# Using configuration file that sets `fileExt` (e.g., `"fileExt": "html,php"`)
npx html-minifier-next --config-file=html-minifier-next.json --input-dir=src --output-dir=dist

# Process all files (explicit wildcard)
npx html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --file-ext='*'

Exclude directories from processing:

# Ignore a single directory
npx html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --ignore-dir=libs

# Ignore multiple directories
npx html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --ignore-dir=libs,vendor,node_modules

# Ignore by relative path (only ignores src/static/libs, not other “libs” directories)
npx html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --ignore-dir=static/libs

Dry run mode (preview outcome without writing files):

# Preview with output file
npx html-minifier-next input.html -o output.html --dry --collapse-whitespace

# Preview directory processing with statistics per file and total
npx html-minifier-next --input-dir=src --output-dir=dist --dry --collapse-whitespace
# Output: [DRY RUN] Would process directory: src → dist
#   index.html: 1,234 → 892 bytes (-342, 27.7%)
#   about.html: 2,100 → 1,654 bytes (-446, 21.2%)
# ---
# Total: 3,334 → 2,546 bytes (-788, 23.6%)

Verbose mode (show detailed processing information):

# Show processing details while minifying
npx html-minifier-next --input-dir=src --output-dir=dist --verbose --collapse-whitespace
# Output: CLI options: collapseWhitespace
#   ✓ src/index.html: 1,234 → 892 bytes (-342, 27.7%)
#   ✓ src/about.html: 2,100 → 1,654 bytes (-446, 21.2%)
# ---
# Total: 3,334 → 2,546 bytes (-788, 23.6%)

# `--dry` automatically enables verbose output
npx html-minifier-next --input-dir=src --output-dir=dist --dry --collapse-whitespace

Special cases

Ignoring chunks of markup

If you have chunks of markup you would like preserved, you can wrap them with <!-- htmlmin:ignore -->.

Minifying JSON content

JSON script types are minified automatically without configuration, including application/json, application/ld+json, application/manifest+json, application/vnd.geo+json, application/problem+json, application/merge-patch+json, application/json-patch+json, importmap, and speculationrules. Malformed JSON is preserved by default (with continueOnMinifyError: true).

Note: The processScripts option is only for script types containing HTML templates (e.g., text/ng-template, text/x-handlebars-template), not for JSON.

Preserving SVG and MathML elements

SVG and MathML elements are automatically recognized as foreign elements, and when they are minified, both case-sensitivity and self-closing slashes are preserved, regardless of the minification settings used for the rest of the file. This ensures valid output for these namespaced elements.

Working with invalid or partial markup

By default, HTML Minifier Next parses markup into a complete tree structure, then modifies it (removing anything that was specified for removal, ignoring anything that was specified to be ignored, etc.), then creates markup from that tree and returns it.

Input markup (e.g., <p id="">foo) → Internal representation of markup in a form of tree (e.g., { tag: "p", attr: "id", children: ["foo"] }) → Transformation of internal representation (e.g., removal of id attribute) → Output of resulting markup (e.g., <p>foo</p>)

For partial HTML fragments (such as template includes, SSI fragments, or closing tags without opening tags), use the partialMarkup: true option. This preserves stray end tags (closing tags without corresponding opening tags) and prevents auto-closing of unclosed tags at the end of input. Note that normal HTML auto-closing rules still apply during parsing—for example, a closing parent tag will still auto-close its unclosed child elements.

To validate complete HTML markup, use the W3C validator or one of several validator packages.

Security

ReDoS protection

This minifier includes protection against regular expression denial of service (ReDoS) attacks:

• Custom fragment quantifier limits: The customFragmentQuantifierLimit option (default: 200) prevents exponential backtracking by replacing unlimited quantifiers (*, +) with bounded ones in regular expressions.

• Input length limits: The maxInputLength option allows you to set a maximum input size to prevent processing of excessively large inputs that could cause performance issues.

• Enhanced pattern detection: The minifier detects and warns about various ReDoS-prone patterns including nested quantifiers, alternation with quantifiers, and multiple unlimited quantifiers.

Important: When using custom ignoreCustomFragments, ensure your regular expressions don’t contain unlimited quantifiers (*, +) without bounds, as these can lead to ReDoS vulnerabilities.

Custom fragment examples

Safe patterns (recommended):

ignoreCustomFragments: [
  /<%[\s\S]{0,1000}?%>/,         // JSP/ASP with explicit bounds
  /<\?php[\s\S]{0,5000}?\?>/,    // PHP with bounds
  /\{\{[^}]{0,500}\}\}/          // Handlebars without nested braces
]

Potentially unsafe patterns (will trigger warnings):

ignoreCustomFragments: [
  /<%[\s\S]*?%>/,                // Unlimited quantifiers
  /<!--[\s\S]*?-->/,             // Could cause issues with very long comments
  /\{\{.*?\}\}/,                 // Nested unlimited quantifiers
  /(script|style)[\s\S]*?/       // Multiple unlimited quantifiers
]

Template engine configurations:

// Handlebars/Mustache
ignoreCustomFragments: [/\{\{[\s\S]{0,1000}?\}\}/]

// Liquid (Jekyll)
ignoreCustomFragments: [/\{%[\s\S]{0,500}?%\}/, /\{\{[\s\S]{0,500}?\}\}/]

// Angular
ignoreCustomFragments: [/\{\{[\s\S]{0,500}?\}\}/]

// Vue.js
ignoreCustomFragments: [/\{\{[\s\S]{0,500}?\}\}/]

Important: When using custom ignoreCustomFragments, the minifier automatically applies bounded quantifiers to prevent ReDoS attacks, but you can also write safer patterns yourself using explicit bounds.

Escaping patterns in different contexts

The escaping requirements for ignoreCustomFragments patterns differ depending on how you’re using HMN:

Config file (JSON):

{
  "ignoreCustomFragments": ["\\{%[\\s\\S]{0,1000}?%\\}", "\\{\\{[\\s\\S]{0,500}?\\}\\}"]
}

Programmatic (JavaScript/Node.js):

ignoreCustomFragments: [/\{%[\s\S]{0,1000}?%\}/, /\{\{[\s\S]{0,500}?\}\}/]

CLI (via config file—recommended):

npx html-minifier-next --config-file=config.json input.html

CLI (inline—not recommended due to complex escaping):

npx html-minifier-next --ignore-custom-fragments '[\\\"\\\\{%[\\\\s\\\\S]{0,1000}?%\\\\}\\\"]' input.html

For CLI usage, using a config file is strongly recommended to avoid complex shell and JSON escaping.

Web demo:

\{%[\s\S]{0,1000}?%\} \{\{[\s\S]{0,500}?\}\}

Working on HTML Minifier Next

Note: This section assumes working with main dependencies installed (npm i).

Local server

npm run serve

Regression tests

cd backtest;
npm i;
npm run backtest

The backtest tool tracks minification performance across Git history. Results are saved in the backtest folder as a JSON file, results.json.

Parameters:

• No argument: Tests last 50 commits (default)
• COUNT: Tests last COUNT commits (e.g., npm run backtest 100)
• COUNT/STEP: Tests last COUNT commits, sampling every STEPth commit (e.g., npm run backtest 500/10 tests 50 commits)

Working tree benchmarks

Where the backtest walks Git history, the benchmark times the code as it is right now—useful for A/B testing a branch against a saved baseline:

cd backtest;
npm i;
npm run benchmark

It reuses the backtest corpus (run npm run backtest once to download it) and reports per-file output size and median processing time.

Parameters:

• No argument: Runs and, if a baseline exists, shows size and time deltas
• --save: Saves the run as the baseline (e.g., on main before switching to a branch)
• --core: Disables the external minifiers (CSS, JS, SVG, URLs) to isolate HMN’s own processing time
• --iterations=N: Sets the number of timed iterations (default 5; the median is reported)
• --config=PATH: Uses an alternative options file (default html-minifier-next.json)

To compare branches (A/B run), execute npm run benchmark -- --save on main, then npm run benchmark on the branch to see the deltas. Add --core on both ends when measuring changes to HMN’s own code rather than the bundled minifiers.

Profiling

To profile the current working tree, run the benchmark with Node’s built-in CPU profiler:

node --cpu-prof benchmark.js

This writes a .cpuprofile file to the working directory. Load it with npx speedscope *.cpuprofile for a flamegraph, or drag it into Chrome DevTools → Sources → JavaScript Profiler. Compare self-time per function against a clean baseline run on main. Pay attention to unexpectedly heavy callbacks in hot paths—V8 de-optimization from variable object shapes or unnecessary method calls can show up there.

Acknowledgements

With many thanks to the previous authors of and contributors to HTML Minifier, especially Juriy “kangax” Zaytsev, and to everyone who helped make this new edition better, particularly Daniel Ruf, Jonas Geiler, and Chris Morgan!

You might like some of my other work:

• Optimization tools: hihtml · HTML Minifier Next · ObsoHTML · CSS Dedup · Image Guard · Compressor.js Next · .htaccess Punk
• Defense tools: IA Defensa
• Resources for quality web development: Articles · Books (including On Web Development) · News · Terminology