Quickly trimming a snippet for inclusion in an HTML bookmarklet or a single-file demo, where you don't have a build chain. Sanity-checking how much "fat" is in a hand-written script before deciding whether a real optimiser is worth setting up. Inlining a small library into a static site without dragging in a bundler. Reducing script size for embedded contexts (iframes, service workers, worker threads) where every byte counts but you're not shipping to production. Testing whether comments or whitespace are actually slowing down your asset delivery (spoiler: they usually aren't on the wire, but this shows the raw difference). Preparing a code snippet for paste into a legacy system that doesn't support comments or multiple lines.

Parse and tokenise. The minifier reads your code and identifies tokens: identifiers, keywords, strings, regex, numbers, comments, and operators. Strip comments. Single-line ( // ) and multi-line ( /* */ ) comments are removed entirely. Content inside strings and template literals is never touched. Collapse whitespace. Multiple spaces, tabs, and blank lines are reduced to single spaces where needed for readability or correctness, removed where safe. Preserve ASI safety. Newlines are kept before statements that would change meaning if joined (e.g. return followed by an object literal on the next line). This prevents subtle bugs without requiring semicolons on every line. Output and compare. The minified code is shown alongside the original, with a byte count and percentage saving so you can judge the impact.

This is structural minify, not a compressor. It won't rename variables, eliminate dead code, mangle properties, or tree-shake imports. For production builds, use terser , esbuild , or swc in your pipeline — they cut another 30–60% on top of structural minify. ASI traps. JavaScript inserts semicolons in surprising places. The minifier preserves a newline where removing it would change meaning (e.g. return {} is not the same as return {} ). Write explicit semicolons in source if you can — it makes minification safer and more predictable. Source maps aren't generated. If you ship minified JS to production, generate source maps with a real toolchain so debugging isn't a nightmare. Modern compression dominates. Brotli or gzip on the wire does most of what minify does. The biggest wins come from removing unused code — that needs static analysis a structural minifier can't do. Don't minify what you commit. Keep source readable in version control. Minify only at build time or deployment.

JavaScript Minifier

Fast structural JavaScript minify — strip comments, collapse whitespace, drop blank lines. See size before/after and the saving percentage.

Input

Output

Enter input above to see the result.

What is this for?

A structural JavaScript minifier strips comments and unnecessary whitespace without changing what the code does. The output is functionally identical to the input — same identifiers, same logic — just shorter. This tool runs that pass in your browser, including the tricky bits: it preserves string contents and regex literals untouched, and keeps newlines where ASI (Automatic Semicolon Insertion) would otherwise change behaviour.

When to use it

Quickly trimming a snippet for inclusion in an HTML bookmarklet or a single-file demo, where you don't have a build chain.
Sanity-checking how much "fat" is in a hand-written script before deciding whether a real optimiser is worth setting up.
Inlining a small library into a static site without dragging in a bundler.
Reducing script size for embedded contexts (iframes, service workers, worker threads) where every byte counts but you're not shipping to production.
Testing whether comments or whitespace are actually slowing down your asset delivery (spoiler: they usually aren't on the wire, but this shows the raw difference).
Preparing a code snippet for paste into a legacy system that doesn't support comments or multiple lines.

How it works

Parse and tokenise. The minifier reads your code and identifies tokens: identifiers, keywords, strings, regex, numbers, comments, and operators.
Strip comments. Single-line (//) and multi-line (/* */) comments are removed entirely. Content inside strings and template literals is never touched.
Collapse whitespace. Multiple spaces, tabs, and blank lines are reduced to single spaces where needed for readability or correctness, removed where safe.
Preserve ASI safety. Newlines are kept before statements that would change meaning if joined (e.g. return followed by an object literal on the next line). This prevents subtle bugs without requiring semicolons on every line.
Output and compare. The minified code is shown alongside the original, with a byte count and percentage saving so you can judge the impact.

Common gotchas

This is structural minify, not a compressor. It won't rename variables, eliminate dead code, mangle properties, or tree-shake imports. For production builds, use terser, esbuild, or swc in your pipeline — they cut another 30–60% on top of structural minify.
ASI traps. JavaScript inserts semicolons in surprising places. The minifier preserves a newline where removing it would change meaning (e.g. return {} is not the same as return {}). Write explicit semicolons in source if you can — it makes minification safer and more predictable.
Source maps aren't generated. If you ship minified JS to production, generate source maps with a real toolchain so debugging isn't a nightmare.
Modern compression dominates. Brotli or gzip on the wire does most of what minify does. The biggest wins come from removing unused code — that needs static analysis a structural minifier can't do.
Don't minify what you commit. Keep source readable in version control. Minify only at build time or deployment.

Limits and reality check

This tool is honest about what it can do. It's good for quick, ad-hoc shrinking and for understanding how much whitespace and comments weigh in your codebase. For anything shipping to users, a proper build tool with dead-code elimination and variable mangling will always win. Use this to get a baseline; use terser or similar to ship production code.