JS Minifier — safe comment & whitespace stripper

JS Minifier tools exist to shrink JavaScript files before they ship to production, and this one does that job in the safest way possible: it removes comments and unnecessary whitespace without ever touching your actual logic. Paste a script into the box above and you will see the before/after byte counts update immediately, along with a clean, copy-ready minified version.

This page is one of the free developer utilities built by Arb Digital, and like the rest of them it runs entirely client-side — no upload, no server round-trip, no third-party library. Everything happens in plain JavaScript in your own browser tab.

What This JS Minifier Does

The tool walks through your source code character by character and removes two categories of "dead weight": comments (both // line comments and /* block comments */) and redundant whitespace, meaning leading indentation, trailing spaces, and repeated blank lines. What it deliberately does not do is rewrite your code's structure. Every statement stays on the line (or lines) it was written on, every variable keeps its original name, and every newline that separates one statement from the next is preserved. That last point matters more than it sounds like it should, and we'll get into why in the next section.

The result is a JS Minifier that trades a little bit of extra compression for a guarantee: if your original code ran correctly, the minified output will run identically, because nothing about the program's meaning was touched — only the parts a JavaScript engine throws away anyway (comments and whitespace) were removed.

How to Use It

1. Paste your code. Drop any JavaScript — a single function, a whole module, an inline script — into the "Paste your JavaScript" box. A sample snippet is preloaded so you can see the tool work immediately.
2. Click Minify JavaScript. The tokenizer runs instantly and the result panel fills in with the before size, after size, bytes saved, and percentage saved.
3. Review the output. The minified textarea is read-only by design, so you can inspect it safely without accidentally editing a half-finished string or regex.
4. Copy it. Click Copy Minified JS to send the result to your clipboard via navigator.clipboard.writeText, then paste it into your build output, a <script> tag, or wherever it needs to live.
5. Re-run anytime. Edit the input and click Minify JavaScript again — there's no page reload needed, and nothing you paste ever leaves your browser.

How Safe JavaScript Minification Works

Under the hood, this JS Minifier uses a small state-machine tokenizer rather than a single find-and-replace regex. That distinction is the entire reason it can be called "safe." As it scans your code left to right, it always knows which of a few possible states it's currently in: plain code, inside a single- or double-quoted string, inside a backtick template literal (including any ${expression} interpolations), inside a regular-expression literal, or inside a comment. Only while in the "plain code" state does it ever strip a comment or collapse whitespace — the moment it enters a string, template literal, or regex, it copies characters through untouched until it sees the matching closing character, correctly skipping over escaped characters like \" or \\/ so it doesn't get fooled into closing early.

This is also why the tool correctly leaves a string like "Discount code: // not-a-comment" completely alone in the sample above — a naive regex-based stripper that just looks for // anywhere in the text would happily chop that string in half. The same protection applies to template literals: the backtick string containing ${items.length} is scanned with brace-depth tracking, so nested braces and nested strings inside the interpolation are handled correctly instead of ending the template literal early.

Regex literals need special handling because the forward slash character is ambiguous in JavaScript — / can either open a regex literal or mean division, and only the token immediately before it tells you which. The tokenizer checks whether the previous significant token was an operator, an opening bracket, or a keyword like return or typeof versus an identifier or closing bracket, where a bare slash almost always means division. This ambiguity is documented in the ECMAScript language specification, and it's part of why writing a fully correct tokenizer by hand is harder than it looks — see the ECMA-262 specification for the full grammar.

Whitespace collapsing works the same conservative way: runs of spaces and tabs are reduced to a single space only where a space is actually needed to separate two tokens, and any run of whitespace containing a newline collapses to exactly one newline — never zero. That single rule is what keeps every statement boundary intact and prevents the minifier from accidentally merging two lines whose combined text would change meaning under Automatic Semicolon Insertion — the JavaScript engine's built-in (and famously quirky) habit of inserting semicolons for you in certain situations.

Why This Isn't a Full Minifier Like Terser/UglifyJS

It's worth being upfront about what this JS Minifier is not: it is not a replacement for a real build-time minifier such as Terser or UglifyJS. Those tools produce smaller output because they don't just tokenize your code — they fully parse it into an Abstract Syntax Tree (AST), a structured representation of every expression, statement, and scope in your program. Once code is an AST, a real minifier can safely rename local variables to single letters (having proven, via scope analysis, the name isn't referenced elsewhere), delete unreachable code, merge statements using explicit semicolons instead of relying on ASI, inline small functions, and fold constants like 2 + 2 down to 4.

All of that requires understanding the full grammar and semantics of JavaScript, not just recognizing where strings and comments start and end. A tokenizer has no concept of "this variable is never read after this point" — it only sees a stream of characters and tokens, not a program's logical structure. Building that deeper understanding safely is a genuinely hard problem: get variable renaming wrong and you break code that relies on a name existing in an outer scope; get statement-joining wrong and you walk straight into an ASI hazard, such as a line starting with ( or [ being read as a continuation of the previous line instead of a new statement.

This tool intentionally stays away from all of that. It sticks to changes that are always safe regardless of your code's structure — removing content the engine discards anyway (comments) and whitespace it never assigns meaning to (except a newline kept for ASI safety). That's a smaller win on paper, but a win with zero risk, which is the tradeoff many developers want for a quick pre-flight pass or a snippet headed into a CMS.

Minification, Bundling, and Compression Are Different Layers

It's easy to lump "make my JS smaller" into one mental bucket, but in a production pipeline it's really three separate layers. Bundling (via Webpack, Rollup, esbuild, or Vite) combines many source files into fewer output files and resolves module imports. Minification — what this page does a safe version of — shrinks the text of that bundled code. Compression, applied by your server or CDN via gzip or Brotli, then shrinks the transmitted bytes further by encoding repeated patterns more efficiently.

These layers have diminishing returns when stacked. Minified code sometimes compresses slightly worse per byte-of-savings, since heavy variable renaming can reduce the repeated byte sequences compression algorithms exploit. In practice the combined effect is still a net win, which is why many teams pair light minification with strong Brotli compression rather than chasing maximum mangling alone.

• Bundling reduces the number of network requests and resolves your module graph.
• Minification reduces the number of bytes inside each file.
• Compression reduces the bytes actually sent over the wire, on top of whatever minification already achieved.

Source Maps and When to Reach for a Real Build Tool

Production teams that use a full mangling minifier also generate a source map — a file mapping every character in the minified output back to its original line, so a production stack trace can still show readable code. A tool like this one doesn't need a source map, because it never renames anything or reorders statements; the output stays recognizable at a glance.

That makes this JS Minifier a good fit for quickly shrinking a snippet before pasting it into a platform with a size limit, cleaning internal comments out of a script before handing it off, or a lightweight step where a full bundler isn't practical. For anything shipping to real end users at scale, a real build tool with AST-based minification and source maps remains the better choice, since the byte savings compound at volume and the tooling exists to offset the added complexity.

Common Mistakes to Avoid

• Assuming any minifier makes code unreadable-safe against theft. Minification (even aggressive mangling) is not obfuscation or security — a determined person can still read minified JavaScript; it only saves bandwidth, it doesn't hide logic.
• Running a naive regex "strip everything after //" script. Without a real tokenizer, this corrupts URLs, strings, and regex literals that legitimately contain two forward slashes — always use a scanner that tracks string, template, and regex state.
• Forgetting to keep an unminified copy. Always keep your original, commented source under version control; minified output is a build artifact, not something you should hand-edit or treat as your source of truth.
• Skipping source maps in production. If you do use a full mangling minifier for a real deployment, generate and upload source maps so error-tracking tools can still show you readable stack traces.
• Minifying already-minified code. Running any minifier on output that's already been through a full build step (like a vendor bundle) rarely helps and can sometimes make debugging harder for no size benefit.
• Treating minification as a substitute for compression. Always serve minified assets with gzip or Brotli enabled at the server or CDN level — skipping that step leaves real savings on the table.

Related Free Tools From Arb Digital

If you work with front-end code and markup regularly, a few of our other free utilities pair well with this one. Try the HTML Minifier for markup files, the CSS Minifier for stylesheets, or the XML to JSON and JSON to XML converters when you're moving data between API formats. Working with copy or documentation instead of code? The Markdown to HTML converter and the HTML Encoder/Decoder are both handy for content workflows. You can browse the complete collection any time on the free tools hub.

Frequently Asked Questions

This tool runs entirely in your browser — nothing you paste here is ever uploaded or sent to a server.