Updated · Built and checked by the PlinzoTools team, formulas tested against published sources
Minify HTML, CSS, or JavaScript by stripping comments and extra whitespace.
Strips comments and redundant whitespace safely -- doesn't rename variables or perform aggressive token-level compression, so it never risks changing your code's behavior.
Minified output will appear here.This tool reduces HTML, CSS, or JavaScript file size by stripping comments and collapsing unnecessary whitespace. It's deliberately a safe minifier -- it doesn't rename variables, eliminate "dead" code, or perform any deeper code transformation, since those more aggressive techniques carry real risk of silently changing how the code behaves.
Select your language (HTML, CSS, or JavaScript), paste your code, and the minified result appears instantly with a size comparison showing the reduction achieved.
CSS: comments and redundant whitespace/line breaks around selectors and declarations.
HTML: comments and unnecessary whitespace between tags.
JavaScript: comments only, using a small tokenizer that correctly distinguishes real comments from lookalike text inside strings, template literals, or regex patterns -- so it never corrupts a string that happens to contain "//" or "/*".
Aggressive JavaScript minification (variable renaming, dead-code elimination, AST-level transforms) is genuinely hard to get perfectly correct -- edge cases like automatic semicolon insertion and regex-vs-division ambiguity have tripped up even mature minification tools. A hand-rolled aggressive minifier risks silently producing broken code, which is worse than a smaller file size. For production-grade aggressive minification, a dedicated build-tool minifier (like Terser or esbuild) is the safer choice.
Quickly shrinking a small CSS or HTML snippet for a lightweight page. Stripping comments from JavaScript before sharing a code snippet publicly. A fast, no-install way to see roughly how much a whitespace/comment pass alone would save, before deciding whether a full build pipeline is worth setting up.
CSS minification is where a whitespace-and-comment pass pays off most, since stylesheets are full of indentation, blank lines, and explanatory comments. A well-commented stylesheet can shrink noticeably. HTML savings are typically smaller and depend on how much indentation and how many comments the file contains. JavaScript sees the smallest change here, because only comments are removed and the code lines keep their structure, so the result is usually not dramatically smaller. The size comparison after each run shows what you actually gained.
Take a stylesheet rule written across several lines with a comment above it: a comment line saying it is the button style, then a selector, an opening brace, two declarations on separate lines, and a closing brace. After minification the comment is gone and the selector, braces, and declarations sit on a single line with the extra spaces removed. Behavior in the browser is identical, but the file has fewer bytes to transfer. Try the tool on your own snippet and compare the byte counts before and after.
Minified code is for delivery, not for editing. Always keep the original, commented version in your project and generate the minified copy when you deploy. Debugging minified code is painful, so if you need to inspect errors in production, consider adding source maps through a build tool. Name minified files clearly, for example with a min suffix, so you never overwrite your source by accident.
File size is one part of performance. Server compression (gzip or Brotli) already shrinks whitespace-heavy text well, so the real-world gain from minification on top of compression is smaller than the raw byte comparison suggests. Combine minification with caching, fewer requests, and only loading the code a page actually needs for larger improvements.
No -- this strips comments and whitespace only, safely. Production build tools (Terser, esbuild, UglifyJS) perform much more aggressive transforms (variable renaming, dead-code elimination) for greater size reduction, at more implementation complexity.
This tool's comment-stripping uses a small tokenizer specifically designed to avoid corrupting comment-like text inside strings, template literals, or regex patterns -- but for critical production code, always test the minified output before deploying.
Yes. Removing comments and extra whitespace does not change how rules apply, so the page should render identically.
For small snippets it is fine, but for production bundles a build-tool minifier is the better fit. Always test the output before deploying.
Only comments are removed from JavaScript in this tool, so files with few comments will see little change.
Somewhat. Compression already handles whitespace efficiently, so the extra savings are smaller, but minification can still help.