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)
Unminify reverses the cheap half of minification: it re-inserts whitespace, line breaks, and consistent indentation, so a one-line bundle becomes readable formatted code. It does NOT reverse the expensive half - the renamer. Variables called a, b, t in the minified bundle stay called a, b, t after unminify, because the original names were discarded at build time and no source map was preserved. If a source map (.map file or inline //# sourceMappingURL= comment) is available, that file points to the original symbols and is the right artifact to load - not an unminify pass. The reader-task framing: unminify is the right tool for "I have a third-party bundle and want to read what it does"; a source map is the right tool for "I have my own build and want to debug original symbols".
Three-minute walkthrough
- 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
Whitespace, line breaks, and indentation are restored deterministically from the AST. Comments are not restored - the minifier strips them at build time, and no information is left in the bundle to reconstruct them. Module structure (CommonJS require calls, ESM import statements) is preserved as it appears in the bundled form, which is often a generated wrapper rather than the original module boundary. Source-level optimisations such as constant folding (5*60*60*1000 collapsed to 18000000) are not reversed - unminify does not understand semantics, only syntax. If a number reads as cryptic in the unminified output, search for it in the original repo or guess at the unit (milliseconds, bytes, indices).
Going the other way?
If you arrived here looking to shrink JS for production rather than expand it, the companion tool at https://freetoolonline.com/developer-tools/js-minifier.html performs the forward direction (whitespace strip, identifier shortening) and the comparison guide CSS Minifier vs Uglifier vs Tree-Shaking covers how the three transformations stack in a typical build pipeline. For CSS-side equivalents, see CSS Unminifier vs Prettier: When to Use Each - the JS-side decision is similar: unminify when reading third-party output, source map when debugging your own.
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.