HTML Minifier Next

HTML Minifier Next (HMN) is a highly configurable, well-tested, JavaScript-based HTML minifier.

The project has been based on Terser’s html-minifier-terser, which in turn had been based on Juriy Zaytsev’s html-minifier (HMN offers additional features, but is compatible with both). It was set up because as of 2025, both html-minifier-terser and html-minifier have been unmaintained for some time. As the project seems maintainable [to me, Jens]—even more so with community support—, it’s being updated and documented further in this place.

Installation

From npm for use as a command line app:

npm i -g html-minifier-next

From npm for programmatic use:

npm i html-minifier-next

Usage

Note that almost all options are disabled by default. Experiment and find what works best for you and your project.

Sample command line:

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

Process specific file extensions:

# Process only HTML files (CLI method)
html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --file-ext=html

# Process multiple file extensions (CLI method)
html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist --file-ext=html,htm,php

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

# Process all files (default behavior)
html-minifier-next --collapse-whitespace --input-dir=src --output-dir=dist
# Note: When processing all files, non-HTML files will also be read as UTF‑8 and passed to the minifier.
# Consider restricting with “--file-ext” to avoid touching binaries (e.g., images, archives).

CLI options

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

Configuration file

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

JSON configuration example:

{
  "collapseWhitespace": true,
  "removeComments": true,
  "fileExt": "html,htm"
}

JavaScript module configuration example:

module.exports = {
  collapseWhitespace: true,
  removeComments: true,
  fileExt: "html,htm"
};

Using a configuration file:

# Specify config file
html-minifier-next --config-file=html-minifier.json --input-dir=src --output-dir=dist

# CLI arguments override config file settings
html-minifier-next --config-file=html-minifier.json --file-ext=xml --input-dir=src --output-dir=dist

Node.js

ESM with Node.js ≥16.14:

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

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

CommonJS:

const { minify } = require('html-minifier-next');

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

See the original blog post for details of how it works, description of each option, testing results, and conclusions.

For lint-like capabilities take a look at HTMLLint.

Minification comparison

How does HTML Minifier Next compare to other solutions, like minimize, htmlcompressor.com, htmlnano, and minify-html? (All with the most aggressive settings, but without hyper-optimization.)

Options quick reference

Most of the options are disabled by default.

Sorting attributes and style classes

Minifier options like sortAttributes and sortClassName won’t impact the plain‑text size of the output. However, they form long, repetitive character chains that should improve the compression ratio of gzip used for HTTP.

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-LD

You can minify script elements with JSON-LD by setting { processScripts: ['application/ld+json'] }. Note that this minification is rudimentary; it’s mainly useful for removing newlines and excessive whitespace.

Preserving SVG elements

SVG elements are automatically recognized, and when they are minified, both case-sensitivity and closing-slashes are preserved, regardless of the minification settings used for the rest of the file.

Working with invalid markup

HTML Minifier Next can’t work with invalid or partial chunks of markup. This is because it parses markup into a tree structure, then modifies it (removing anything that was specified for removal, ignoring anything that was specified to be ignored, etc.), then it creates a markup out of 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>)

HMN can’t know that the original markup represented only part of the tree. It parses a complete tree and, in doing so, loses information about the input being malformed or partial. As a result, it can’t emit a partial or malformed tree.

To validate 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.

Running benchmarks

Benchmarks for minified HTML:

cd benchmarks
npm install
npm run benchmarks

Running local server

npm run serve

Acknowledgements

With many thanks to all the previous authors of HTML Minifier, especially Juriy Zaytsev, and to everyone who helped make this new edition better, particularly Daniel Ruf and Jonas Geiler.