HTML Minifier Compress HTML, Inline CSS, and Inline JavaScript

What an HTML minifier actually does

An HTML minifier takes a document that a person wrote and produces a smaller version that a browser will render the same way. It does this by removing characters the browser does not need in order to understand the page: comments left for other developers, indentation that makes the source easier to read, and blank lines between sections. The result is a file that is functionally identical to the original but takes fewer bytes to store and transfer.

The tool on this page goes a step further than most simple minifiers. It also compacts the contents of any inline <style> and <script> blocks, so a page with a large amount of inline CSS or JavaScript benefits twice. It protects content that must be preserved, including everything inside <pre> and <textarea> elements, JSON-LD structured data blocks, and the whitespace that appears between two inline elements.

Nothing here is unusual. Minification has been part of web publishing for well over a decade, and most build systems run some version of it on every deployment. What this page gives you is a quick way to do the same thing without setting up a build pipeline, which is useful for a one-off landing page, a widget embed, an email template, or a small static site that does not warrant a full toolchain.

How HTML whitespace really works

The trick to minifying HTML safely is understanding which whitespace matters and which does not. In most places, a run of spaces, tabs, and newlines between two tags is insignificant. The browser collapses any run of whitespace in normal text to a single space when rendering, and the whitespace between two block elements has no visible effect at all. Those two facts are what make minification possible without changing the output.

Three cases break the rule. The first is whitespace between two inline elements, where a space has a real visual effect. If you write <span>a</span> <span>b</span> the space between the spans is rendered, and if a minifier strips it the two spans will touch. The second is inside <pre> and <textarea> blocks, where every space and line break is significant and must be preserved exactly. The third is in content that is read by something other than a browser, such as a JSON-LD block that a search engine parses, where reformatting can occasionally confuse a strict parser.

This tool handles those three cases explicitly. The whitespace between two inline elements is preserved, the contents of <pre> and <textarea> blocks are pulled out and returned unchanged, and JSON-LD and JSON script blocks are skipped during JavaScript minification. Everything else is treated as fair game for whitespace removal, which is where the savings come from.

What is safe to remove, and what is not

Four categories of characters are removed or compressed by this tool, and it is worth knowing what each one is so you can decide which options to leave on.

HTML comments. Comments left for other developers, such as <!-- TODO: fix layout -->, are removed when the Remove HTML comments option is checked. The exception is conditional comments used by legacy Internet Explorer templates, which are kept by default because some deployment systems still depend on them. If you are certain you no longer support those clients, you can turn off the Keep conditional comments option to strip them as well.

Whitespace between block tags. Indentation that aligns nested tags with each other is collapsed to a single character and then removed where it appears between two tags whose inline status does not matter. The exact rule is conservative: two adjacent tags are only merged if neither is a known inline element. That means a <div> followed by a <p> on the next line becomes a single string, but a <span> followed by a <strong> keeps the space that separates them.

Whitespace inside the contents of inline CSS blocks. When the Minify inline CSS option is on, any <style> block in the document has its contents compacted. Block comments are removed, runs of whitespace are collapsed, and whitespace around CSS operators such as {, }, :, ;, ,, and > is stripped. Strings, url() contents, and quoted selectors are preserved exactly.

Whitespace and comments inside the contents of inline JavaScript blocks. When the Minify inline JavaScript option is on, every <script> block except those with a type of application/ld+json or application/json is compacted. Line comments, block comments, and formatting whitespace are removed. Strings, template literals, and regular expression literals are preserved by a small tokeniser that tracks quote state and distinguishes regex literals from division operators based on the preceding token.

How the inline CSS and JavaScript minifiers work

The CSS minifier is a small character-by-character scanner. It walks the input once, tracking whether it is inside a string, inside a block comment, or inside an url() token. When it is inside any of those three contexts it copies characters verbatim. When it is outside them, it collapses runs of whitespace to a single space and removes spaces that sit next to an operator. The result is a compact but valid stylesheet.

The JavaScript minifier is more careful, because JavaScript has more contexts in which a slash can mean different things. A // starts a line comment, a /* starts a block comment, but a single / can be either a division operator or the start of a regular expression literal. The minifier decides which one it is by looking at the last significant character that it has already emitted: if that character is one that cannot end an expression — a brace, a bracket, a comma, a semicolon, an operator, or one of the keywords return, typeof, case, and so on — then the slash is treated as the start of a regex and copied through to its closing slash, including any character class inside square brackets. Otherwise it is treated as a division operator and copied as a single character.

Neither minifier tries to be clever. It does not rename variables, does not reorder rules, does not inline values, and does not remove unreachable code. Those transformations belong to specialised tools that understand the semantics of the language and the surrounding program. The minifiers here do one job, do it safely, and stop. That is why they can run in a browser tab with no build step, and why the output is predictable: the same input will always produce the same output, and a diff between two runs will only contain whitespace and comment differences.

A worked example, byte by byte

Consider a small HTML fragment that a developer has just finished writing. It has a couple of comments, a style block, a script block, and about ten lines of indented markup. The original file, as pasted into the tool, is 640 bytes on disk.

When Remove HTML comments is on, the two comments are stripped. That saves roughly sixty bytes on this example, which is a little under ten per cent of the total. When Minify inline CSS is on, the style block is compacted from four formatted rules into a single line, saving another fifty bytes. When Minify inline JavaScript is on, the script block is compacted from six indented statements into a single line, saving about eighty bytes. The whitespace collapse at the end removes another hundred and twenty bytes of indentation, blank lines, and inter-tag spaces.

The final file is around three hundred and thirty bytes, a reduction of just under half. The largest single contributor is the whitespace collapse, which is typical for hand-formatted source. The second largest contributor depends on the file: for a page with a lot of inline logic it will be the JavaScript minifier, and for a page with a lot of inline styling it will be the CSS minifier. The byte-savings breakdown on the results panel above tells you which stage mattered most for the file you actually pasted in.

Two points are worth noting about this example. First, the reduction is much larger than what a typical production page would see, because production pages usually go through a build step that already handles most of this. A page that has already been minified will see single-digit savings. Second, none of the reductions come from removing content. Every byte that was removed was a character the browser did not need to render the page, which is why the output looks identical in a browser window.

Common mistakes that break a page

Several mistakes come up repeatedly when people minify HTML, and each one is worth knowing about before you publish a minified file.

Assuming whitespace never matters. It usually does not, but it sometimes does, and the cases are not always obvious. A space between two inline images, a newline inside a text node that is being used for layout, and a space that separates two adjacent links are all examples of whitespace that a naive minifier would remove and a careful one would keep. This tool takes the conservative route, but if you are working with a template you did not write yourself, it is still worth comparing the minified output with the original in a browser.

Forgetting conditional comments in email templates. Email HTML is unusually sensitive to conditional comments, tracking placeholders, and whitespace between inline-block elements. The defaults on this page are aimed at web pages, not at email. If you are minifying an email template, turn off the comment removal option and test the output in the actual mail clients your audience uses. Better still, use a purpose-built email build tool for recurring campaigns.

Minifying generated code that will be regenerated. If your deployment runs a build step that already produces minified output, running this tool on the result accomplishes very little. Worse, if you edit the minified file directly and then rebuild, your edits disappear. Treat the readable source as the file you edit and the minified version as a build artifact, and put the same minification decisions into your build pipeline so every deployment is consistent.

Assuming minification is a security measure. It is not. Removing whitespace and comments does not remove a cross-site scripting vulnerability, does not sanitise user input, and does not repair a broken Content Security Policy. If a page contains a script that should not be there, minifying it will simply make that script smaller. Security work is a separate exercise with separate tools.

Minifying a page that is already slow for other reasons. A page can be uncompressed, unminified, and still fast, or compressed, minified, and still slow. The larger performance wins usually come from delivering images at the right size, removing unused CSS and JavaScript, and caching aggressively. Minification is real but small, and treating it as the main fix for a slow page is a mistake.

Losing the readable source. Once a file has been minified, the comments and formatting are gone. They cannot be recovered by any beautifier, because the beautifier would have to guess where they used to be. Always keep a readable source file in version control and treat the minified version as a copy, not the original.

Skipping the browser test. The most important step is also the simplest. Open the minified output in a browser, click through the page, submit the form, resize the window, and check that nothing has moved. If the page looks the same, the minification did its job. If something is off, you have found a case the tool did not handle, and the readable source is still there to fix it.

A sensible workflow for using this tool

Four steps cover almost every use of a minifier, and following them in order avoids most of the problems people run into.

Start from a readable source. Save the file you are about to paste somewhere safe, ideally under version control. The minifier cannot be undone, and a source file is the only way to get the comments and formatting back if you need them later.

Paste and choose options based on your target. For a web page, leave all four options on and let the tool do the full job. For an email template, turn off the comment removal and test the output carefully. For a fragment that will be embedded in a framework that parses whitespace-sensitive content, turn off the whitespace options and just minify the inline CSS and JavaScript.

Compare the byte counts. The summary panel shows you the original size, the minified size, the bytes saved, and the percentage reduction, along with a breakdown of how much each stage contributed. If the reduction is small and you expected it to be large, one of the options is probably off, or the input was already minified. If the reduction is large but the output looks wrong in the browser, the problem is usually a whitespace-sensitive construct the tool could not see.

Test in the browser and keep the source. Open the minified output, walk through the page, and confirm that it renders correctly. Then save the minified file alongside the source, not in place of it. For a repeatable workflow, take the same options you used here and put them into a build script so you do not have to remember them next time.

Where minification helps, and where it barely matters

Minification reduces the number of bytes that have to be stored, transferred, parsed, and cached. On a slow connection, that reduction can be measured in fractions of a second. On a fast connection it is often too small to notice, which is why the technique is one of the smaller levers available to a web developer rather than one of the bigger ones.

The place where minification matters most is when compression is not available. An uncompressed HTML file sent over a metered mobile connection will benefit directly from every byte that is removed. A file sent over HTTP/2 with Brotli compression has already had most of its redundancy removed by the compressor, so the additional benefit of minification is small. Both techniques are worth using, but the order matters: enable compression first, then minify.

The second place where minification helps is when the file is very large. A one-megabyte HTML document, which is unusual but not unheard of for a heavily templated marketing page, will shrink by a meaningful amount that shows up directly in a Lighthouse report. A ten-kilobyte document will not. The tool does not care either way, and the byte counts on the results panel give you a clear signal about which situation you are in.

The third place is when the document contains a large amount of inline CSS or JavaScript. A page that embeds a full stylesheet or a script library inline benefits twice: once from the whitespace collapse on the HTML structure and once from the minification of the inline content. Those are the pages where a run of this tool produces a genuinely useful result, and they are usually the pages where the developer knows they are not going to set up a full build pipeline.

Where this tool stops

This minifier is a practical utility, not a production build tool. It is fast, safe, and predictable, but it does not know about frameworks, templates, or the specific quirks of a given deployment system. Its defaults are aimed at standard HTML documents, and its CSS and JavaScript minifiers handle the common syntaxes without trying to be language-complete.

Three limitations are worth stating plainly. First, it does not parse HTML, which means it cannot reason about which whitespace is significant based on the surrounding structure. It uses a conservative rule based on the tag names on either side of the whitespace, and that rule handles the vast majority of real documents but not all of them. Second, it does not rename CSS classes, HTML IDs, or JavaScript variables, because doing so safely would require understanding every reference to those names across the whole page and any external files it depends on. Third, it does not verify that the minified output is semantically identical to the input. It only guarantees that the bytes it removed are the ones a browser is documented not to need.

For projects that ship frequently, the right place for minification is a build step. Tools like esbuild, Vite, Webpack, and the various HTML minifier plugins handle this automatically, and they know more about the code than any standalone tool can. This page is for the cases those tools do not cover: a one-off landing page, a widget that will never touch a build system, a fragment that needs to fit inside a character limit, or a quick sanity check on how much a file would shrink if you did set up a pipeline. When you outgrow it, move on to the real thing. Until then, it will do the job.

Sources

The whitespace rules and inline-element behaviour this tool relies on are documented in the HTML specification and in widely used web development references. The sources below are the ones that carry the most weight for this subject.