What does a code minifier do?
A minifier removes everything a browser does not need: comments, indentation and the whitespace between tokens that a parser would discard anyway. The file that a developer reads and the file that a visitor downloads do not have to be the same, and for CSS and JavaScript the difference is routinely a third of the bytes or more.
This one is deliberately conservative. Real minifiers — the ones in a build pipeline — also rename variables, inline functions, drop unreachable code, fold constants and mangle property access. That is worthwhile, and it needs a full parser plus a model of every scope in the file, because the transformations change behaviour when they are wrong. This tool performs only the subset that cannot change behaviour: comment removal and whitespace reduction, with each language's specific hazard protected.
So it is a tool for the cases a build step does not cover. A one-off stylesheet pasted into a CMS, a snippet being measured to see how much is actually overhead, a theme file in a system that has no task runner, a quick check of what a framework's output would look like minified. For anything that goes through a bundler, the bundler's own minifier will do a better job, and that is the honest answer.
How to minify code
- Choose the language: CSS, HTML or JavaScript. The mode decides which comments and which whitespace are safe to remove.
- Paste the source into the box, or press Load an example to see the tool with something typical in it.
- Read the result as you type. The byte count next to the buttons shows the original size, the minified size and the percentage saved.
- Check the guarded parts if the file has any: calc() in CSS, pre and textarea in HTML, and line breaks in JavaScript should all be where they were.
- Copy the minified code or download it as minified.css, minified.html or minified.js, whichever matches the mode.
- Keep the original. The output is for serving, not for editing — a minified file is painful to maintain by hand.
Code Minifier limits and rules
| Item | Limit |
|---|---|
| Languages | CSS, HTML and JavaScript, one at a time |
| CSS guard | calc() expressions are held aside and restored untouched |
| HTML guard | pre, textarea, script and style content is left as written |
| JS guard | Strings, template literals and regular expressions are scanned so // inside them is not a comment |
| Line breaks | A whitespace run containing a newline becomes one newline, not a space |
| Size shown | Raw byte counts, before any server compression |
| Not done | Renaming, mangling, dead-code removal, constant folding or source maps |
| Not covered | TypeScript, JSX, SCSS, Less and other languages that need a compile step first |
When to use it
- Minifying a stylesheet or snippet for a CMS that has no build pipeline.
- Seeing how much of a file is whitespace and comments before deciding whether to bother.
- Compacting a JavaScript file that is loaded directly with a script tag.
- Producing a tidier HTML fragment for a template engine that preserves the input exactly.
- Checking that a minified build output still contains the calc() values it should.
Is it private?
The source code is parsed and rewritten by JavaScript running in this page. Nothing is uploaded, stored or logged, and the tool works with the network disconnected once the page has loaded.
Frequently asked questions
Rarely as much as the number suggests. Almost every server compresses responses with gzip or Brotli, and those algorithms are excellent at exactly the redundancy a minifier removes — repeated keywords, indentation, comments. A file that minifies to 35 per cent smaller may be only a few per cent smaller once compressed, because the compressor had already thrown that redundancy away. Minify anyway for the parse time and the memory, but measure the compressed transfer size before believing a headline saving.
Because renaming variables safely requires knowing every scope in the file, every closure, every use of eval and every property that is accessed dynamically. Get any of those wrong and the code breaks in a way that only appears at runtime, in a specific path. This tool does not parse the code that far, so it does not attempt the transformations that need it. Use a real build-time minifier such as esbuild or terser when you want renaming, and treat this as the safe subset.
Because JavaScript inserts semicolons automatically at line breaks in specific positions, so joining lines can silently change what the code does. A function that begins with return on one line and a value on the next returns undefined; collapse the newline and it returns the value. Since the scanner cannot tell a meaningful line break from a cosmetic one, it keeps one newline wherever there was a run of whitespace containing one. That costs a few bytes and prevents a class of bug that is genuinely hard to find.
It is preserved exactly. A plus or minus inside calc() is an operator only when it has whitespace on both sides, so calc(100% - 2rem) is arithmetic while calc(100%-2rem) is invalid. The usual "strip spaces around punctuation" step would break every such expression. The tool lifts each calc() out, minifies the surrounding CSS, and puts the expressions back, so a minified stylesheet has the same computed values as the original.
Yes, that is the point of the JavaScript scanner. A naive minifier strips everything from // to the end of the line, which turns the URL in const api = "https://example.com/v1" into const api = "https: and then a syntax error. This scanner tracks single quotes, double quotes, template literals, their escape sequences and regular expressions, so a // or /* inside any of those is treated as content rather than as a comment. CSS and HTML have no equivalent ambiguity, and their handling is correspondingly simpler.
No. Keep the readable source under version control and treat the minified output as a build artefact, exactly as you would treat any other generated file. Comments that explained a workaround are gone, names that were chosen for clarity are unchanged here but will be mangled by a build tool, and a single line thousands of characters long is miserable to diff. The point of minifying is the bytes on the wire, not the file on disk.
Related tools
Written and maintained by Md. Nur Hossain Repon.