Unminify JS: Restore Readability of Minified JavaScript
Minified JavaScript collapses a bundle to one dense line with one-letter variable names. Paste it into the online JS unminifier and the tool re-inserts whitespace, line breaks, and indentation in seconds - no upload, no install, nothing sent to a server. Variable names stay shortened; only whitespace structure is restored.
Last reviewed: 2026-05-20
Free Tool Online editorial team| Property | Value |
|---|---|
| Format | Online tool, no install |
| Typical bundle size handled | Up to ~5 MB in modern browsers |
| Processing speed | Under 2 s for bundles under 500 KB |
| Privacy | Source stays on-device; nothing uploaded |
| Variable rename | Not performed - one-letter names remain one-letter |
| Implementing tool | https://freetoolonline.com/developer-tools/js-unminifier.html |
What unminify actually does (and what it cannot do)
What unminify actually does is re-insert whitespace, line breaks, and indentation from minified JavaScript so you can read a one-line bundle - it cannot recover original identifier names shortened at minify time.
Three-minute walkthrough
Three-minute walkthrough: paste minified JS into JS Unminifier (or open a .js file if the page offers upload), run the beautify pass, then copy the indented output for stack-trace reading - all in the browser, no tracking upload of your code beyond what the page states.
- Copy the minified bundle. Open the
.min.jsfile in your editor or the browser's network tab (Response body), select all, copy. - Paste into the editor. Open https://freetoolonline.com/developer-tools/js-unminifier.html and paste into the input pane. Long bundles - hundreds of KB or more - work, but expect the format pass to take a second or two while the parser walks the AST.
- Click Unminify. The right pane shows the indented output. Copy the result back into your editor or save it as a local
.jsfile for grep-style reading.
Where the unminified output helps and where it does not
Reading unminified third-party code is useful in three concrete situations. First, vulnerability triage - when a CVE names a function inside a vendor bundle, unminify lets you locate the call sites and read the surrounding flow without standing up the original repo. Second, behaviour confirmation - when a library's behaviour drifts between versions, diffing the unminified versions surfaces the change far faster than reading the dense one-line form. Third, build-output verification - when your own pipeline emits a bundle that mysteriously double-loads a polyfill, the unminified form shows the duplicate IIFE blocks at a glance. Unminify will not help when the goal is the original semantic names; for that, ship the source map alongside the bundle and load it in your debugger.
What is preserved, what is lost
What is preserved, what is lost in JS Unminifier: whitespace, line breaks, and indentation come back from the parse tree; comments and original short names like a/b/fn1 stay gone because minifiers discarded them at build time.
What identifier names look like after unminify
Unminify restores whitespace and structure - it does not recover original identifier names. Local variable names shortened by the minifier (single letters like a, b, fn1) stay shortened because the minifier discarded them at build time. However, exported function and class names are usually preserved: minifiers skip shortening exported symbols so the module API stays intact. If the bundle was minified with a standard tool like terser or esbuild, top-level exported names will be readable after unminify; only internal local variables will remain synthetic. Load the source map in your browser debugger if you need the full original symbol table.
Going the other way?
Going the other way? To shrink JS for production rather than expand it, use the JS minifier - it removes whitespace, comments, and shortens local identifiers (while keeping exported names intact). For one-off minification the browser tool is enough; for CI pipeline builds, a CLI tool like terser or esbuild is faster on large codebases.
FAQ
Does unminify recover the original variable names?
No. Minifiers replace identifiers with short synthetic names at build time and discard the originals; the unminified output keeps the synthetic names. Load the matching source map in your browser's debugger to see the original symbols.
Is the source uploaded anywhere?
No. The unminify pass runs entirely in your browser; the minified text is never sent to a server. Close the tab and the input is gone.
Will unminify break the JavaScript?
No. The transformation is purely cosmetic - whitespace, line breaks, and indentation. The AST is unchanged, so the unminified code runs identically to the minified original. Run it through a syntax checker if you want a belt-and-braces confirmation.
What is the file-size limit?
Bundles up to several megabytes work in modern browsers; the format pass time grows roughly linearly with input length. Very large bundles (10 MB+) may stutter the tab; in that case split the bundle by closure boundary and unminify each chunk separately.
What is the difference between unminify and prettier?
Unminify restores readable formatting to code that was deliberately compacted. Prettier (or a similar formatter) imposes a chosen style guide on already-readable code. For a third-party minified bundle, unminify first; if you then want a specific indent width or quote style, run prettier on the output.
When your goal is to produce smaller JS rather than read it, the guide how to minify css js for cloud run cold start covers the build-pipeline steps for stripping both CSS and JS before container deployment.