JavaScript Minifier
Minify JavaScript locally, compare raw and gzip savings, and catch syntax, module-scope, comment, console, and source-map risks.Current status
{{ minifiedCode }}
| Metric | Value | Detail | Copy |
|---|---|---|---|
| {{ row.metric }} | {{ row.value }} | {{ row.detail }} |
| Setting | Status | Impact | Copy |
|---|---|---|---|
| {{ row.setting }} | {{ row.status }} | {{ row.impact }} |
Introduction
Readable JavaScript is written for review first. People use line breaks, indentation, descriptive names, comments, and logging while they are building or debugging code. A browser does not need most of that authoring shape to execute the same program, so a delivery copy can often be much smaller than the file a developer wants to read.
JavaScript minification is more sensitive than removing whitespace from plain text because code has scope, syntax targets, comments that may carry license notices, and names that outside code may call. A safe pass can remove layout and compress expressions while keeping function and class names readable. A production pass may shorten local names, which is useful only when those names are truly private to the file or module.
Byte savings and delivery savings are related, but they are not the same. Raw bytes tell you how many UTF-8 bytes were removed from the file text. A gzip estimate tells you how the same text may compress for transport. Code with repeated names and repeated formatting can already compress well, so a large raw reduction may produce a smaller gzip improvement than expected.
Source maps add a practical tradeoff. They make debugging easier by connecting generated positions back to original positions, but they can expose original source text and names to anyone who receives the map. Console and debugger removal has a similar review cost: it can shrink output, but it can also remove diagnostics that a support or operations workflow still uses.
The safest minified JavaScript is not merely the smallest text. It is code that parses under the intended module or script rules, targets the right runtime syntax, keeps required comments, treats public names carefully, and is tested in the page or runtime that will load it.
How to Use This Tool:
Choose the code ownership and runtime assumptions first, then read the size and option checks before using the generated file.
- Paste code into JavaScript source, drop text onto the textarea, or choose Browse JS. JS, MJS, CJS, and TXT files are read locally, and input over 1 MB is stopped before minification.
- Choose Minify profile. Start with Safe compression for reviewable output, use Whitespace only when you want layout cleanup without expression rewrites, and choose Production bundle only for closed files where local-name shortening is acceptable.
Production bundle can shorten local names. If the file is a classic script with public globals, keep Top-level scope off unless those names are fully owned.
- Set Comment policy. Keep license comments keeps comments that begin with an exclamation mark, Keep all comments is useful during review, and Strip all comments should wait until required notices are checked.
- Turn on Module mode for files that use import or export syntax. Leave it off for classic scripts, widgets, CMS snippets, or browser globals that other scripts may call.
- Open Advanced only when deployment requirements call for it. Set ECMAScript output when an older runtime needs constrained syntax, turn on Drop console/debugger only when diagnostics are disposable, use ASCII-only output for ASCII-only delivery paths, and enable External source map only when the map can be shared safely.
- Read the summary and warnings. Fix Syntax Review Needed before changing profiles, enable Module mode when the module warning appears, and compile TypeScript-like syntax to JavaScript before minifying.
Size Audit reports raw byte savings and gzip estimates separately; a missing gzip row means the current browser cannot measure compression streams.
- Use Minified JS only after Size Audit and Option Ledger match the way the file will be loaded. If External source map is enabled, inspect Source Map JSON before sharing the map.
Interpreting Results:
The headline percentage is the raw UTF-8 reduction for the generated JavaScript. It is useful for quick comparison, but it does not prove that the output is safe. Runtime tests still matter when compression rewrites expressions, local names are shortened, console calls are removed, a source map is generated, or an ECMAScript target changes the emitted syntax.
| Signal | What It Means | What to Check Next |
|---|---|---|
| Syntax Review Needed | The source did not parse under the selected script or module assumptions. | Use the line, column, and snippet to fix the source before trying another profile. |
| Bytes saved | The generated JavaScript uses fewer raw UTF-8 bytes than the input. | Run the output in its real page, worker, or runtime before treating it as production-ready. |
| Gzip rows | The browser estimated compressed transfer size for input and output. | Use these rows as delivery clues, then confirm production server compression separately. |
| Option Ledger | The current profile, comment policy, syntax target, scope handling, console/debugger choice, and source-map choice were applied. | Recheck this table before copying code for a different loading context. |
| Source Map JSON | A separate mapping artifact is available when source maps are enabled. | Treat the map as sensitive if original source or private names should not be exposed. |
The false-confidence trap is trusting a high reduction percentage while ignoring scope or runtime assumptions. A smaller file still needs a syntax-clean run, a matching option ledger, and a runtime test in the environment that will execute it.
Technical Details:
JavaScript minification starts with parsing. Invalid JavaScript cannot be safely rewritten because the minifier must understand tokens, statements, expressions, and scope before it can remove or transform anything. Once parsing succeeds, compression can remove unreachable code, fold constants, combine declarations, shorten syntax, and remove layout characters that are not needed for parsing.
Name shortening is governed by scope ownership. A local variable inside a function can often be renamed because no outside code can reach it by its original name. A top-level name in a classic script may be called by inline handlers, other scripts, tests, or browser-console workflows. ES modules usually make top-level declarations private unless they are exported, which is why module handling changes the safety of top-level optimization.
Formula Core
Raw size savings use UTF-8 byte counts. Raw saved bytes are floored at zero for display, while gzip reduction can show either a gain or a loss when the browser can estimate compressed streams.
For example, a 20,000 byte source that becomes 7,600 bytes saves 12,400 raw bytes and reports a 62.0% raw reduction. If gzip estimates are 5,200 bytes before minification and 3,900 bytes after minification, the transport-size estimate improves by 25.0% because the original code already contained repeated text that compressed well.
Transformation Core
| Stage | Mechanism | Review Boundary |
|---|---|---|
| Parse | The source text must form valid JavaScript in the selected module or script context. | TypeScript, JSX, or other extensions should be compiled to JavaScript first. |
| Compress | Equivalent expressions, declarations, unreachable branches, and whitespace are reduced according to the profile. | Expression rewrites still need runtime tests in the actual loading environment. |
| Shorten names | Allowed local identifiers may be replaced with shorter names when the production profile enables name shortening. | Top-level names stay public unless module mode or top-level scope ownership says otherwise. |
| Format output | Comments, semicolons, ASCII escaping, and ECMAScript target constraints shape the emitted text. | License notices, old runtimes, and ASCII-only systems need deliberate settings. |
| Map generated code | An optional source map relates generated positions back to original positions and source names. | Source maps can expose original source content and private names. |
Profile and Scope Rules
| Setting | Technical Effect | Use When |
|---|---|---|
| Safe compression | Compression is enabled while function and class names stay readable. | Manual review, stack readability, or cautious handoff matters. |
| Production bundle | Compression and local-name shortening are enabled. | The file is closed enough that private names can be changed. |
| Whitespace only | Expression compression and name shortening are disabled. | You want layout cleanup without code rewrites. |
| Module mode | The parser and optimizer treat the source as an ES module. | The file uses import or export syntax. |
| Top-level scope | Top-level names may be optimized when the selected profile allows it. | The outer names are not a public API for other code. |
Advanced Tips:
- Keep Safe compression for snippets that will be inspected by people or reported in stack traces, because function and class names remain readable.
- Use Production bundle with Module mode or a deliberately enabled Top-level scope only when outside code does not depend on those top-level names.
- Keep Drop console/debugger off when logs are part of expected behavior, diagnostics, instrumentation, or support workflows.
- Set an explicit ECMAScript output only when a deployment target requires older syntax; otherwise Auto avoids unnecessary constraints.
- Review Source Map JSON before sharing it, because a map can reveal original source text and names even when the minified file looks opaque.
- Use the gzip rows in Size Audit as delivery estimates, not exact server measurements; production headers and compression settings can change the final transfer size.
Limitations, Privacy, and Accuracy:
The selected JavaScript is minified in the browser after the required minifier and source-map support load. The minification run does not upload the pasted source, but network access may be needed to load those browser dependencies if they are not already cached.
- The local preview accepts up to 1 MB, or 1,048,576 bytes, of JavaScript source.
- Minification is not linting, type checking, dependency analysis, security review, or runtime testing.
- TypeScript, JSX, and other syntax extensions should be compiled to JavaScript before minification.
- Gzip estimates depend on browser support for compression streams and may not match production server compression.
- Source maps should be treated as sensitive when original source content or private names should not be public.
Worked Examples:
Use these cases to match the settings to the way the JavaScript will actually be loaded.
Reviewable CMS widget
A classic script exposes window.priceWidget and is pasted into a CMS theme. Use Safe compression, keep license comments, leave Module mode and Top-level scope off, and check that Option Ledger reports classic scope handling. The final proof is loading a test page that still calls the public global.
Closed ES module handoff
An MJS file uses import and export syntax and ships through a controlled deployment path. Turn on Module mode, leave ECMAScript output on Auto unless an older runtime requires a target, and use Production bundle only after local-name shortening is acceptable. Option Ledger should show ES module scope before the output is copied.
Failed paste with TypeScript syntax
A pasted snippet contains annotations such as count: number. The summary may show Syntax Review Needed or the warnings may say TypeScript-like syntax should be compiled first. Compile the source to JavaScript, paste the compiled code into JavaScript source, then compare Bytes saved and gzip estimates again.
FAQ:
Why did minification stop on a syntax error?
The source must parse before safe output can be generated. Fix the reported line, column, and snippet first; changing from Safe compression to another profile will not repair invalid JavaScript.
Should I enable Module mode for every file?
No. Enable Module mode for ES module files that use import or export syntax. Leave it off for classic scripts, browser globals, widgets, and files that other scripts call through top-level names.
Why are raw savings and gzip savings different?
Raw savings compare UTF-8 bytes before and after minification. Gzip savings estimate compressed transfer size, so repeated source text can already compress well before minification.
Is it safe to strip all comments?
Only when no required license or preservation notice depends on those comments. The default license policy keeps comments that begin with an exclamation mark.
Do source maps make minified code private?
No. Source maps help debugging tools relate minified code to original positions, and they can include original source content. Share Source Map JSON only where that exposure is acceptable.
Glossary:
- Minification
- Generating smaller JavaScript text that should preserve the intended runtime behavior.
- Compression
- Syntax-preserving reductions such as folding expressions, removing unreachable branches, and dropping unneeded layout characters.
- Name shortening
- Replacing allowed local identifiers with shorter names to reduce bytes.
- Top-level scope
- The outermost declarations in a file, which may be public in a classic script and private in an ES module unless exported.
- Source map
- A JSON mapping that connects generated JavaScript positions back to original source positions for debugging.
- Gzip estimate
- A browser-measured compressed-size estimate for the input and minified JavaScript.
- ECMAScript target
- The output syntax level selected when older or constrained JavaScript runtimes need specific syntax.
References:
- Terser minify options, Terser documentation.
- ECMA-426 Source map format specification, Ecma International, December 2024.
- JavaScript modules, MDN Web Docs, 4 April 2026.
- Compression Streams API, MDN Web Docs, 6 September 2025.