Minification is deletion under constraints, and the constraints are where
the damage happens. We ran the exact minifier functions from our component
on fixed samples and hostile edge cases, and we measured every number in the
stats bar. Here is what the tool deletes, what it protects, and the four
inputs where it changes what your code does.
Measured on three fixed samples
The stats bar counts UTF-8 bytes with TextEncoder and divides saved bytes by
original bytes, so multi-byte characters count correctly. Our runs:
language original minified saved
HTML 228 B 156 B 72 B (31.6%)
CSS 121 B 72 B 49 B (40.5%)
JavaScript 134 B 92 B 42 B (31.3%)
The CSS sample, with comments and padded colons, shrank most. Your files
will differ with comment density and indentation style. The percentage is a
property of the input, never a promise about your code.
What each pass deletes
The HTML pass removes every comment, collapses all whitespace between tags,
and reduces runs of two or more whitespace characters to one space. The
CSS pass removes comments, strips spaces around braces, colons, semicolons,
commas, and the combinator characters, drops the semicolon before a closing
brace, and removes spaces inside braces. The measured CSS output went from
padded declarations to a single tight line with no semicolon before the
final brace.
The JavaScript pass walks the source character by character. It skips over
single-quoted, double-quoted, and template strings so comment removal never
eats a string. A line comment becomes a newline, which preserves automatic
semicolon insertion, and a block comment becomes a single space. A later
pass removes spaces around a safe operator set, collapses blank lines, and
drops newlines that follow operators or precede closing brackets.
What it keeps on purpose
Two behaviors survived our tests by design.
Newlines between statements stay. A run with two const declarations on two
lines kept its line break, because joining statements that rely on automatic
semicolon insertion would break them. The tool removes newlines only after
operators and opening symbols, where no statement can end.
String literals survive the comment scanner intact. A quoted greeting kept
its spaces through the JS pass in the measured sample. The scanner copies
string bytes verbatim, so an apostrophe inside a comment never ends a string
early, and a quote inside a string never starts a comment.
Four inputs where it breaks things, all verified
1. Inline element spacing. The HTML rule that collapses whitespace between
tags also removes the meaningful space between inline elements. Our test
input of a bold tag, one space, and an italic tag came out with the two
tags touching, which joins two words on screen. If your design puts two
inline elements next to each other, keep a character between them or use
a minifier that understands inline context.
2. Conditional comments. The HTML pass deletes every comment, and the code
notes this itself. Pages that still ship Internet Explorer conditional
blocks lose those branches entirely. Legacy pages are the exact pages
people point at a minifier, so check for conditionals first.
3. Regular expression literals. The JS scanner protects three quote types
and nothing else. A regex literal containing spaces around a plus sign
came back with those spaces removed, and the newline after a regex that
ends in a slash was deleted because the pass treats that slash as an
operator. Our test joined two statements into one broken line. Any regex
in your code is a reason to test the output before you use it.
4. Whitespace inside strings and template literals. The global whitespace
passes run after the string scanner, over the whole output including
string contents. In our measured run, a string with two spaces between
letters came back with one space, and a template literal lost padding
around its interpolation. If your strings carry meaningful spacing, this
minifier changes program output, not just file size.
That fourth case is the most expensive one, because the minified file still
parses. Nothing throws. The program simply prints different text.
Behavior notes worth knowing
The language tab persists in localStorage under the key codeminify-lang, so
your next visit opens on the same mode. Switching tabs clears the input, so
finish one job before you change languages. The download button names the
file minified.html, minified.css, or minified.js to match the tab.
The rule for production
Use this tool for quick inspection, small static assets, and snippets on
the way into a CMS. For production bundles, use an AST-based minifier such
as Terser, which parses the code instead of pattern-matching it. Our own
FAQ page gives the same advice, and the four breakage cases above are the
reasons why.
Checklist before you use minified output
- Search the source for regex literals before running the JS pass.
- Check inline element pairs for lost spaces after the HTML pass.
- Confirm no conditional comments exist in the HTML source.
- Diff string contents, not just byte counts, when strings contain runs of
spaces.
- Load the minified file once in a browser before you publish it.
Steps for a safe run
1. Paste the code with the correct language tab selected.
2. Read the savings number, then ignore it and inspect the output.
3. Run the four breakage checks from the list above.
4. Copy or download the output.
5. Test the deployed file, not the local copy, once.
If you have a file where this minifier corrupted something not on our list
of four, that case belongs in a regression list. Run your own samples and
watch the stats bar in the code minifier at
https://webrecast.com/en/code-minifier
