JavaScript Minifier
{{ summaryHeadline }}
{{ summaryLine }}
Disabled draft {{ profileLabel }} {{ formatBytes(inputBytes) }} input {{ formatBytes(outputBytes) }} output {{ gzipSavingsLabel }}
Safe keeps names readable, Bundle enables mangling, and Whitespace only avoids semantic rewrites.
Keep license banners by default; strip all comments for the smallest local preview.
Paste one JavaScript file or snippet; minification runs locally in the browser.
Drop JS, MJS, CJS, or TXT onto the textarea.
{{ fileStatus }}
Use Auto unless a deployment target requires older output syntax.
Use a short file stem without an extension; downloads append .min.js and .map.
Turn on for ES modules; leave off for browser globals, widgets, or classic scripts.
{{ module_mode ? 'Module' : 'Classic script' }}
Turn on only when top-level names are not part of a public API.
{{ toplevel_scope ? 'Closed bundle' : 'Preserve top level' }}
Leave off when logs are part of expected runtime behavior.
{{ drop_console ? 'Dropped' : 'Kept' }}
Turn on when the output must pass through ASCII-only systems.
{{ ascii_only ? 'Escaped' : 'Unicode kept' }}
Turn on when the minified file needs debugger mapping back to this source.
{{ source_map ? 'Generated' : 'Omitted' }} 
{{ minifiedCode }}
Metric Value Detail Copy
{{ row.metric }} {{ row.value }} {{ row.detail }}
Setting Status Impact Copy
{{ row.setting }} {{ row.status }} {{ row.impact }}
Tags: Devtools, Text
Export to PDF Fullscreen
Customize
Advanced
:

JavaScript minification reduces source text into a smaller program that a browser can still parse and run. Most size savings come from removing comments and layout whitespace, shortening safe syntax patterns, and sometimes renaming local variables. The result is meant for delivery or review, while the original source remains the version people should read and maintain.

Smaller JavaScript can reduce transfer size and make deployment artifacts easier to compare, but minification is not the same as proving a release is correct. A compressed file may look healthy because it is shorter while still carrying a syntax error, a removed debug statement that someone needed, or a renamed top-level symbol that another page expects. Good minification work keeps the size goal tied to the runtime contract.

Comment policy matters because JavaScript comments can carry licensing and preservation notices. Keeping comments that start with an exclamation mark is a common compromise for distribution, while stripping every comment is only suitable when the legal and handoff context allows it. Source maps add another tradeoff: they make transformed code easier to debug, and they can also expose the original source if distributed without care.

JavaScript minification flow from source text through parsing and compression to minified code, source map, and size audit.

Technical Details:

Parser-backed minification starts by turning JavaScript text into syntax that can be analyzed. If the parser cannot understand the source, no trustworthy minified output exists, so line and column feedback is more useful than a partial result. Once parsing succeeds, compression removes unreachable code, folds simple expressions, joins declarations, and rewrites some constructs into shorter equivalent forms.

Name mangling is separate from compression. It shortens local identifiers only when the selected policy allows it, and top-level names need extra care because they may be part of a public interface. Output formatting then decides whether comments are kept, whether non-ASCII characters are escaped, and whether the generated syntax should be constrained to a selected ECMAScript output level.

Source maps connect positions in transformed code back to the source that produced them. They are useful for debugging stack traces and breakpoints after minification, but they should be handled as source-adjacent material because generated maps can include source content and symbol names.

Stage What changes Review concern
Parse JavaScript source is checked before any output is produced. Syntax errors stop the run and should be fixed in the source text.
Compress Whitespace, unreachable code, repeated patterns, and simple expressions are reduced. Runtime tests still matter because smaller code is not proof of correct behavior.
Mangle Allowed local names can be shortened; closed top-level scope can be optimized when selected. Public names, globals, and integration points can break if treated as private.
Format Comments, semicolons, Unicode escaping, and output syntax level are applied. License comments and older deployment targets may need deliberate settings.
Map An optional source map points debugging tools back to the original source. Map files should be shared only where source exposure is acceptable.
Setting Behavior Best fit
Safe compression Compression is enabled, name mangling is off, and function and class names stay readable. Draft review, test builds, and handoffs where stack names remain useful.
Production bundle Compression uses two passes and local-name mangling is enabled. Closed bundles where public names and top-level scope have been checked.
Whitespace only Compression rewrites and name mangling are disabled while formatting still removes layout noise. Low-risk cleanup when semantic rewrites are not wanted.
Module mode Source is treated as an ES module, which also implies top-level scope handling. Files that use import or export.
Drop console/debugger Compression removes console.* calls and debugger statements. Release drafts after confirming logs are not part of expected behavior.
External source map A map artifact is generated and the minified output includes a source map reference comment. Debugging transformed code without reading the compressed file directly.
Signal What triggers it What to do
Syntax Review Needed The parser reports a line, column, or syntax message before output is available. Fix the highlighted source area, then rerun and check the summary again.
Module syntax warning The source appears to use module syntax while Module mode is off. Enable Module mode for ES modules, or keep classic mode for browser globals.
TypeScript-like syntax warning The source appears to contain type declarations or annotations. Compile TypeScript or JSX to plain JavaScript before minifying it here.
Input over 1 MB The pasted or selected source exceeds the browser-side preview limit. Use a smaller file or run a build-pipeline minifier for larger bundles.

Everyday Use & Decision Guide:

Start with Safe compression and Keep license comments for a first pass. That combination gives a smaller result while keeping names readable and preserving comments that commonly carry distribution notices. Check the Size Audit before copying anything, because the byte reduction, gzip estimate, and run time tell you whether the change is meaningful enough for the handoff.

Switch to Production bundle only when the source is a closed bundle. If another page expects a top-level function or variable to keep its name, leave Top-level scope off or keep the safer profile. For ES modules, turn on Module mode so import and export code is treated as module scope instead of classic browser-global code.

Whitespace only is useful when you want a compact draft without compression rewrites. It can make review diffs smaller, but it should not be mistaken for a production optimizer. Drop console/debugger also deserves a deliberate check: removing debug statements is normal for many releases, yet some applications intentionally use logging for diagnostics or embedded support flows.

  • Use Minified JS to inspect the exact generated code before copying or downloading it.
  • Use Option Ledger when you need to explain which profile, comment policy, syntax target, scope mode, and source map choice produced the output.
  • Use JSON when a run record should travel with metrics, warnings, and selected options.
  • Enable External source map only when the receiver needs debugger mapping back to the source.

A short result is not automatically a safe result. Treat warnings, syntax messages, and unexpected output size as stop signs, then run the minified code through the same tests you would use for the original source.

Step-by-Step Guide:

  1. Choose Minify profile. Use Safe compression for review, Production bundle for closed release bundles, or Whitespace only when you only want layout cleanup.
  2. Set Comment policy. Keep license comments unless you have already confirmed that every notice can be removed from the distributed artifact.
  3. Paste JavaScript into JavaScript source, drop a JS, MJS, CJS, or TXT file onto the editor, or use Browse JS. If the file is over 1 MB, the page reports the browser-side limit and waits for a smaller input.
  4. Open Advanced when the source needs a fixed ECMAScript output, Module mode, closed top-level scope, console removal, ASCII-only output, or an external source map.
  5. Read the summary headline after the run. A percent-smaller headline means output is ready for review; Syntax Review Needed means the parser stopped and the source should be fixed at the reported line and column.
  6. Open Minified JS for the code, Source Map JSON when map output is enabled, Size Audit for byte and gzip signals, and Option Ledger for settings evidence.
  7. Copy or download the result only after warnings are clear or understood, then test the minified code in the application context that will run it.

Interpreting Results:

The summary headline is a size signal, not a correctness verdict. A value such as 42.0% smaller means the current output has fewer UTF-8 bytes than the input before transport compression. The gzip badge, when available, estimates compressed-transfer savings with the browser compression API, so it may be blank in browsers that do not expose that feature.

Size Audit is the best place to judge the run. Source bytes and Minified bytes show raw size change, Bytes saved shows the main reduction percentage, and Minifier time helps spot unusually slow local runs. A low byte reduction is not a failure when the source was already compact or when Whitespace only was selected.

Option Ledger explains why two runs with the same source can differ. Production bundle enables mangling while Safe compression keeps names readable. Module mode and Top-level scope change how top-level bindings are treated. Comment policy changes whether license banners, all comments, or no comments are emitted.

Do not overread clean output. A successful minification run means the source parsed and Terser returned code under the selected options. It does not prove that a renamed symbol, removed console call, source map exposure, or older ECMAScript target choice is safe for the application that will use the file.

Worked Examples:

Review a small widget before handoff

A pricing widget with three product rows, a totalCents function, and one console.log call is a good first pass for Safe compression. Keep the comment policy on Keep license comments if the source starts with a /*! banner. The Minified JS tab should produce readable function and class names, while Size Audit shows the source bytes, minified bytes, bytes saved, gzip estimate when supported, and minifier time.

Prepare an ES module bundle carefully

A module that imports formatPrice and exports renderCart should use Module mode. If Production bundle is selected, the Option Ledger should show an ES module scope status and a profile impact that mentions local-name mangling. Review Minified JS before shipping, because a module bundle can tolerate more top-level optimization than a classic script only when the import and export contract is correct.

Recover from a source error

A pasted TypeScript fragment such as type Item = { cents: number } can trigger the TypeScript-like warning, and a broken JavaScript snippet can move the summary to Syntax Review Needed. The recovery path is to compile TypeScript to plain JavaScript or fix the reported line and column, then rerun until Minified JS appears and JSON records a null error.

FAQ:

Does minification prove my JavaScript is safe to deploy?

No. It proves only that the source parsed and returned minified output under the selected options. Run application tests, especially after enabling Production bundle, Top-level scope, Drop console/debugger, or a fixed ECMAScript output.

Why would I keep license comments?

The default comment policy keeps comments that begin with an exclamation mark because those comments often carry license or preservation notices. Strip all comments only after confirming that the distributed code does not need them.

When should Module mode be turned on?

Turn it on for source that uses ES module syntax such as import or export. Leave it off for classic scripts that intentionally publish top-level names to a browser-global context.

What does the source map option create?

It creates a separate JSON map and adds a source map reference comment to the minified code. Use it when debugging transformed code matters, and handle the map carefully because it can reveal original source content.

Is my pasted code sent to a server for minification?

After the page and minifier libraries load, pasted code and selected files are processed in the browser. This tool has no server-side minification endpoint, and the one-file preview limit is 1 MB.

Glossary:

Compression
Minifier rewrites that reduce code size by removing unreachable code and shortening safe expressions.
Mangling
Identifier shortening, usually for local names, that can reduce size but needs scope awareness.
Top-level scope
Names declared outside nested functions or modules, which may be public in classic scripts.
ECMAScript output
The syntax level requested for generated JavaScript formatting.
Source map
A JSON mapping that helps debugging tools relate minified code positions back to source positions.

References: