Minify JavaScript With Terser
Minify JavaScript with Terser to shrink file size and speed up your site, right in your browser.
Your source stays on your device
Nothing to delete afterwards
Built for proprietary code
Works in every modern browser
How it works
- 1
Paste your JavaScript
A module, a script, or a snippet you want smaller before it ships.
- 2
Check the result
Compare sizes and read the warnings before you replace anything.
- 3
Copy the output
Take it into a build output, a template, or an inline script tag.
Why use this tool
Safe local renaming
Only bindings the tool can see every reference to are shortened, which is what keeps the output working.
Before and after sizes
The raw saving shown next to what it becomes after compression, which is the number that matters.
Syntax errors reported
Invalid input says where it failed instead of producing output that breaks at load time.
Comments removed, directives kept
Licence headers and `"use strict"` survive, because dropping them silently changes behaviour or breaches a licence.
Nothing is uploaded
The code is processed in your browser, so proprietary source never reaches a server.
Free, no account
No signup, no watermark, no cap on how much you minify.
The saving comes from renaming, not from deleting spaces
Stripping whitespace and comments is the visible part and the smaller part. Most of the reduction in a real file comes from mangling: every local variable, parameter, and function name is replaced with one or two characters, so `calculateTotalPrice` becomes `t` and a descriptive codebase collapses. That is also where the entire risk lives. A minifier can rename a binding safely only when it can see every place that binding is referenced, which it can for anything scoped inside a function. It cannot see a reference that was made from a string, and those references are exactly what breaks. Understanding this one distinction explains every minification bug you are likely to meet, and it tells you where to look when minified code fails and the original works.
What must not be renamed, and why the tool cannot tell
The dangerous cases all share a shape: a name that is written as text somewhere the minifier does not read as code. Accessing a property as `obj["someKey"]` while writing it as `obj.someKey` elsewhere means one form gets renamed and the other does not. Object keys that must match a JSON payload from an API are the same problem — rename the key and the request stops matching the server. Older dependency-injection frameworks read parameter names to decide what to inject, which is why minifying an AngularJS application without the annotation step was a famous way to break it entirely. Anything that inspects `Function.name` or a class name at runtime, including some serialisation and logging code, has the same exposure. The practical rule: names that cross a boundary — a network payload, a template, a string lookup — must be quoted and left alone.
Source maps make the output debuggable, and can leak your source
Minified code produces a stack trace pointing at line 1, column 48,000, which is useless. A source map is the standard fix: a separate file mapping positions in the output back to the original, so a browser shows you the code you wrote. Generate them — the alternative is debugging production blind. The part worth planning is where the map lives. A source map contains your original source, usually including the comments you removed, and if it sits at a publicly reachable path referenced by a comment at the bottom of your bundle, anyone can fetch it and read your unminified code. That is fine for open source and a genuine disclosure otherwise. The usual answer is to upload maps to your error-tracking service and not serve them publicly, or restrict them to authenticated requests.
Minification is not obfuscation and protects nothing
It is worth stating plainly because the belief is common: shortening names does not hide logic. Minified code can be re-indented by any formatter in one step, and while the names are gone the structure, the strings, the API endpoints, and the algorithm are all intact and readable. Anyone who wants to understand your client-side code will, and they will do it in minutes. This matters because it leads to real mistakes — an API key committed into a bundle on the assumption that minification conceals it, or a feature flag checked client-side and treated as an access control. If code or a value must stay secret, it cannot ship to a browser at all; the only reliable boundary is your server. Deliberate obfuscators exist and raise the effort somewhat, at a serious cost in size and speed, and they do not change that conclusion.
Compression on the wire does most of what people credit to minification
The framing of minification as a bandwidth saving is a decade out of date, because everything is served with gzip or brotli now, and those algorithms are extremely good at exactly what minification removes. Repeated whitespace and long repeated identifiers compress to almost nothing, so a minified file and a formatted one often differ far less after compression than before it — which is why the size that matters is the compressed one, and why this tool shows both. Minification still earns its place for two other reasons: less source means less for the browser to parse and compile before anything runs, which is measurable on mobile, and the bytes are smaller before compression too. But if you are choosing where to spend effort on bundle size, removing unused code beats mangling names by a wide margin.
Why minifying locally matters for this kind of text
The input to a minifier is source code, and source code is the thing a company least intends to publish. It carries your endpoint URLs, your internal function and module names, the comments explaining what a workaround is for, occasionally a key that should not be there, and the structure of a system that took real effort to design. Pasting a proprietary file into a hosted minifier sends all of that to a third party in exchange for a size reduction you could have had locally. This tool processes the code in the page and transmits nothing, which you can confirm in the Network tab of your developer tools — and for the one text type that is literally your employer’s intellectual property, that is the sensible default.
Common mistakes to avoid
- Mixing `obj.someKey` and `obj["someKey"]` for the same property. One form gets renamed and the other does not, so the two stop referring to the same thing after minification.
- Renaming keys that must match a network payload. Object keys sent to or received from an API are matched as strings by the server — quote them so the mangler leaves them alone.
- Relying on parameter or function names at runtime. Dependency injection by parameter name and logic that reads `Function.name` both break, because those names are exactly what mangling replaces.
- Publishing source maps to a public path. A source map contains your original code including removed comments — upload it to your error tracker rather than serving it beside the bundle.
- Treating minification as protection. Minified code re-indents in one step and the strings, endpoints, and algorithm are all still readable, so nothing secret can ship to a browser.
How it compares
| Aspect | This tool | Online minifiers | A build pipeline |
|---|---|---|---|
| Source sent to a server | Never | Usually yes | No |
| Compressed size shown | Yes | Rarely | With a plugin |
| Setup required | None | None | Configuration |
| Removes unused code | No | No | Yes |
| Account or signup | Not needed | Sometimes required | Not needed |
| Price | Free | Free / paid tiers | Free |
Features
Identifier mangling
Local variable and function names shortened, which is where most of the reduction comes from.
Whitespace and comment removal
Everything the parser ignores is dropped, including the newlines that make the file readable.
Compression-aware sizing
Both the minified size and the compressed size, since only the second reaches the user.
Modern syntax supported
Classes, arrow functions, template literals, optional chaining, and module syntax are all understood.
Handles large files
Whole bundles minify without an upload or a size cap.
Reversible formatting
A beautify mode too, because reading minified third-party code is a common need.
Nothing to install
No build tool, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no content tracking and no third-party upload.
Who uses it
Front-end developers
Shrinking a standalone script that is not going through a build step.
Web performance engineers
Comparing minified and compressed sizes to see where the saving actually is.
Developers reading third-party code
Using the beautify direction to make a minified library readable enough to follow.
Anyone inlining a script
Getting a small snippet down to a size that is reasonable to embed in a page.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.