(This project has been based on Terser’s html-minifier-terser, which in turn had been based on Juriy Zaytsev’s html-minifier. 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 will be updated and documented further in this place. For the time being, the following documentation largely matches the original project.)

HTMLMinifier is a highly configurable, well-tested, JavaScript-based HTML minifier.

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

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

For command line usage please see html-minifier-next --help for a list of available options.

Sample command line:

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

const { minify } = require('html-minifier-next');
const result = await minify('<p title="blah" id="moo">foo</p>', {
  removeAttributeQuotes: true,
});
result; // '<p title=blah id=moo>foo</p>'

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.

How does HTMLMinifier compare to other solutions, like minimize or htmlcompressor.com?

Most of the options are disabled by default.

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

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

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

SVG tags 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.

HTMLMinifier 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>)

HTMLMinifier can’t know that original markup was only half of the tree; it does its best to try to parse it as a full tree and it loses information about tree being malformed or partial in the beginning. As a result, it can’t create a partial/malformed tree at the time of the output.

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.

(Further improvements are needed. Contributions welcome.)

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.

Benchmarks for minified HTML:

cd benchmarks
npm install
npm run benchmark

npm run serve

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