JavaScript Lexical Minifier

Parse and compress JavaScript scripts safely using a lexical scanner to strip comments, space, and console logs.

Drop a JavaScript script file or click to uploadAccepts .js, .ts, .mjs

Source Script

JavaScript Input Code

Input size: 315 bytes

Minification Parameters

Comment Handling

Mangle Local NamesStrip Console statements

Minification Insights

315

Original Size (B)

184

Minified Size (B)

-42%

Reduction

Compression Ratio Meter42% saved

Minified JavaScript Output

function greet(name){
const message="Hello, "+name+"!";console.log(message);console.info("Greeting completed.");return message;}
function add(a,b){
return a+b;}
const PI=3.14159265359;

Estimated Network Load Speeds

Slow 3G (400 Kbps)0.004s

Fast 3G (1.6 Mbps)0.001s

Cable Broadband (30 Mbps)0.000s

Lexical JavaScript Minification

JavaScript Minification reduces script files by analyzing and restructuring code tokens. Unlike naive text-replace methods, our lexical tokenizer groups code blocks into structured types (strings, keywords, symbols, regex, whitespace) to perform changes without causing runtime issues.

Custom parameters allow developer settings like keeping vital license headers (/*! / @preserve), stripping diagnostic console.log() blocks, and mapping local identifiers to shorter symbols. Size comparisons and transfer speeds help estimate real performance boosts in production.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Checking how much a standalone script shrinks before adding a build step.
Producing a compact snippet for an inline handler or a bookmarklet.
Stripping comments from a file before sharing it externally.
Estimating the transfer size of a script you cannot rebuild.
Comparing two implementations on size with formatting removed from both.

Frequently Asked Questions

What does minification actually do?: Removes whitespace and comments, shortens local variable names, and applies safe syntactic transformations — collapsing `if` statements into ternaries, dropping unreachable code. It cannot rename anything reachable from outside the module.
How is it different from bundling?: Bundling combines modules and resolves imports; minifying shrinks the result. Tree-shaking sits between them, removing exports nothing imports — and it usually saves far more than minification does, because it deletes whole functions rather than whitespace.
Why can minified code break?: Because some patterns defeat static analysis. Code relying on `Function.prototype.toString`, on a function's `name`, or on property access by a computed string can all be invalidated by renaming — which is why frameworks that use constructor names need configuration.
Are source maps safe to deploy?: They expose your original source to anyone who fetches them, which is fine for open code and not for proprietary logic. The common arrangement is generating them and uploading to an error tracker rather than serving them publicly.
How much does minification save after compression?: Less than the raw figure suggests, because gzip and brotli already handle repetition well. Minification typically cuts 30–40% raw and adds perhaps 10–15% on top of compression — real, and smaller than the headline number implies.

Common errors and gotchas

Minifying code that depends on automatic semicolon insertion, where a removed line break changes meaning.
Removing a comment that was a directive, a licence header or a bundler hint.
Expecting the savings of a real minifier. Renaming and dead-code elimination do most of the work, not whitespace.
Minifying a file that has a source map, which then no longer corresponds to anything.
Assuming minified means obfuscated. The logic is entirely readable once reformatted.