Free JavaScript Minifier Online

You've got a script sitting in a <script> tag or a small utility file, it's carrying comments and generous formatting, and you need it smaller before it goes anywhere near production. A JavaScript minifier handles exactly that: it strips comments and collapses unnecessary whitespace from your source so the file transfers faster, without touching the actual logic. This one runs live in your browser — paste code in, watch the minified version appear in the pane next to it as you type — and it's built for the fast, one-off pass rather than a full build pipeline. Below is how the tool works, where minifying JavaScript actually pays off, what a conservative, comment-and-whitespace minifier does differently from a tool like Terser, and when you genuinely need the heavier option instead.

How the JavaScript Minifier Works

The interface is a two-pane editor: source on one side, minified output on the other, refreshed continuously as you edit rather than on a click.

• Paste your JavaScript into the left pane, or upload a .js file if it's too long to comfortably paste.
• The output pane updates as you type. Every edit triggers an immediate re-pass, so there's no separate "minify" button to hunt for and no waiting on a spinner.
• Line comments and block comments are removed, along with extra blank lines and repeated whitespace between tokens, while variable names, function names, and the code's actual structure stay exactly as written.
• Grab the result with the copy button, or download it as a .js file if you're going to drop it straight into a page or a script tag.

Nothing you paste is sent off for processing — the transformation happens locally the instant you type. If you need this behavior outside a browser tab, say as part of a script that processes files on a server or in CI, the same logic is exposed as an API call at /docs; send it JavaScript source in the request body and get the minified text back, billed at one credit per call.

Why Minify JavaScript

Full build tooling isn't always the right amount of effort for what you're trying to do. A quick, browser-based minifier earns its keep in a specific set of situations:

• A bookmarklet. Browser bookmarklets have to live inside a single javascript: URL, and every character counts toward what's practical to paste into a bookmark's URL field. Stripping comments and whitespace before you save it keeps the bookmarklet manageable.
• A one-off script embedded in a static page. If a site has no build step at all — a handwritten HTML page with a <script> tag — minifying the script by hand before deployment is often the only "optimization" step that page will ever get.
• Inline event handlers or widget snippets. Third-party embed snippets, tracking pixels, and small widget scripts that get pasted into a CMS text field benefit from being compact, since some fields impose character limits or simply load faster with less to parse.
• Sanity-checking size before you commit to a library choice. Pasting a small utility or polyfill into the tool gives you a rough sense of its minified footprint before deciding whether to bundle it or write your own version.
• Sharing a compact snippet in a support ticket or forum post. When formatting doesn't need to survive, a smaller block of code is easier for someone else to paste and test quickly.

What This Minifier Does — and Deliberately Doesn't Do

JavaScript is a much riskier language to minify aggressively than CSS or HTML, because so much of its syntax is context-sensitive. A forward slash can mean division or the start of a regular expression depending on where it sits. Automatic semicolon insertion means removing a newline in the wrong place can silently change what a statement means. Template literals can contain arbitrary characters, including ones that look like comment delimiters. A minifier that doesn't fully parse the code into an abstract syntax tree has to be careful about exactly what it touches.

This tool takes the conservative route: it removes comments and collapses excess whitespace and blank lines, but it does not rename variables, does not inline constants, does not eliminate dead code branches, and does not restructure control flow. Tools like Terser or esbuild's minifier do all of that, but they can only do it safely because they parse your code into a full AST first, understand scope, and apply transformations that are provably behavior-preserving. Text-based comment and whitespace stripping skips that entire analysis step, which is exactly why it's fast and dependency-free — and also why it stops short of the deeper size reductions a real bundler-integrated minifier achieves.

In practice, that tradeoff is the right one for the use cases this tool targets. You're not shipping a 500KB application bundle through it; you're shrinking a snippet, a bookmarklet, or a small script, and you want to be confident the logic hasn't changed underneath you.

One honest limitation worth calling out directly: this tool does not strip console.log or other debug statements, the way a production build configured with Terser's compress options often does. If a script still has debug logging scattered through it, minifying here will shrink the whitespace and comments around those calls but leave the calls themselves fully intact. That's a deliberate choice — automatically deciding which function calls are "debug only" and safe to delete requires understanding intent, not just syntax, and getting it wrong in either direction (stripping a call that mattered, or leaving one that leaks internal state into a production console) is exactly the kind of risk a conservative, text-based tool is built to avoid. If you need debug statements removed as part of minification, that's a job for a bundler-integrated minifier with an explicit drop-console option, applied deliberately rather than as a side effect. The same blanket approach applies to comments generally, including license headers at the top of a file — since the tool doesn't distinguish comment types, a license notice gets removed along with everything else. If a script's license requires that header to survive in distributed copies, keep an unminified original on hand and reattach the notice manually afterward.

Aspect	This Minifier (comment/whitespace)	Terser / esbuild (AST-based)
Comment removal	Yes	Yes
Whitespace collapsing	Yes	Yes
Variable/function renaming (mangling)	No	Yes
Dead code elimination	No	Yes
Source map generation	No	Yes
Setup required	None — browser tab	npm install, bundler config
Best suited for	Snippets, bookmarklets, quick pastes	Production application bundles

JavaScript Minifier vs Terser, esbuild, and UglifyJS

If you're shipping an application through a bundler already, reach for the dedicated package instead of a browser tool:

• Terser. The standard choice behind most modern build tools, with variable mangling, dead code removal, and configurable compression passes. It requires Node and a bundler integration (webpack, Rollup) to get real value out of.
• esbuild's built-in minifier. Extremely fast, written in Go, and bundled directly into esbuild's build step — the natural pick if esbuild is already your bundler, but it's not something you'd install just to minify a single file by hand.
• UglifyJS. An older but still-used option, mainly relevant now for projects that haven't migrated to ES2015+ syntax support elsewhere in their toolchain.
• A browser-based JavaScript minifier. No install, no config, works from any device, and shows the result as you type. It won't get you the aggressive size reduction a mangling minifier does, but for a single script or snippet you weren't going to run through a bundler anyway, that gap rarely matters.

The practical rule: if the code is already flowing through webpack, Vite, or esbuild, let that pipeline's minifier handle it — it's doing more, and it's already there. Reach for this tool when there's no pipeline in the picture at all, just a script that needs to be smaller right now.

How Your Code Is Processed

Everything happens inside your browser tab using JavaScript running on your own machine — the code you paste or upload is never transmitted to a server for processing, and nothing is retained once you navigate away or close the tab. That's a meaningful detail if the script contains internal API logic, unreleased feature code, or anything else you wouldn't want passing through a third party's servers, since with this tool it simply doesn't.

Common Questions About Minifying JavaScript

Does this obfuscate my code?

No. Obfuscation deliberately makes code hard to read — renaming variables to meaningless strings, restructuring control flow. This tool only removes comments and whitespace; anyone who runs it through a formatter afterward gets back something very close to the readable original, just with the documentation gone.

Can it break code that uses regular expressions or template literals?

It's built to avoid that. Regex literals and template literal contents are left intact rather than having their internal characters treated as whitespace to collapse, which is exactly the class of bug that makes naive text-based JS minifiers risky if they're not careful about it.

Should I use this instead of Terser for a production bundle?

No — for an actual production application bundle, use Terser or esbuild through your build tool. They handle mangling and dead code elimination that meaningfully reduce transfer size at scale. This tool is for individual scripts and snippets outside that pipeline.

Will it work on modern syntax like arrow functions or async/await?

Yes. Since the tool doesn't parse or rewrite the logic itself, any valid modern JavaScript syntax — arrow functions, async/await, optional chaining, destructuring — passes through unchanged aside from comments and whitespace being stripped.

How much smaller will my file get?

That depends on how much was comments and formatting to start with. A heavily documented file can shrink noticeably; tightly written code with few comments won't shrink much, since there isn't much to remove beyond incidental whitespace.

Does it strip console.log statements or other debug code?

No. Comments and whitespace are removed, but every function call — including logging and debug statements — stays exactly where it was. Deciding what counts as safe-to-delete debug code requires understanding what the script is doing, not just its syntax, so this tool leaves that decision to you rather than guessing.

Related Tools

If your project spans more than just script files, a few other tools cover the rest of the stack. Shrink accompanying stylesheets with the CSS Minifier, or clean up markup with the HTML Formatter when readability matters more than file size. Debugging a config object or API payload the script depends on? JSON Formatter makes dense JSON readable again. Comparing two versions of the same script before and after an edit is easier with the Code Diff Tool, which highlights exactly what changed line by line. And if the script leans on pattern matching, the Regex Tester lets you validate expressions against sample input before they go anywhere near production.