Developer Tools·4 min read

How to Unminify JavaScript and Read Minified Code

Minified JavaScript is written for machines: every space removed, every local variable renamed, the whole file on one line. That's great for load times and miserable for humans. This guide covers how to unminify JavaScript with the JS Beautifier, what the restored code can and can't tell you, and the habits that make vendor scripts and production bundles readable enough to debug. You won't get original variable names back, nothing can do that without a source map, but you'll get structure, and structure is most of what reading code requires.

Open the free JS Beautifier All insights

Why you're staring at a one-line vendor file

The scenario.

The error tracker says the exception came from widget.min.js, line 1, column 51,203. You don't own that file, there's no repository to check, and the vendor's support queue is three days deep. Or maybe a tag manager snippet is doing something odd to your analytics and you'd like to know exactly what before it ships to every page on the site.

Minified files are normal and healthy in production; they exist so browsers download less. The problem starts the moment a human needs to read one. Nobody hands you the source, so the practical skill is turning what you have into something readable, quickly and without installing a toolchain.

How to unminify JavaScript in one click

Open the JS Beautifier and paste the minified source into the Input pane, or click Upload file to load one from your computer. Click Beautify and the tool runs js-beautify in your browser, putting one statement per line and indenting each block by its nesting depth. Click Copy for the result, or Download .js to save it as a .formatted.js file next to the original. The Try sample button loads a compressed one-liner if you want to see the effect first. Nothing gets uploaded, which matters when the script belongs to a client or contains keys you haven't audited yet.

A few settings sit above the panes. Indent switches between 2 spaces, 4 spaces and tabs. Braces puts opening braces on the same line, on their own line, or on the same line with else moved to a new line. Keep blank lines, on by default, preserves the empty lines already in your source. Match these to your team's style and the output drops into a diff without noise. Behavior stays identical either way, since only whitespace and line structure change.

A worked example, before and after

Here's a one-liner of the kind a minifier produces. Input: function greet(name){console.log("Hello, "+name);return true}greet("MyToolStudio");

With the default settings, the same code comes back as five readable lines: the function declaration opens the block, console.log("Hello, " + name); sits indented inside it, return true follows, the closing brace gets its own line, and the greet("MyToolStudio"); call lands at the end. Trivial at this size, sure. But paste in 80 KB of vendor bundle and the identical transformation is the difference between guessing and reading.

Reading bundles when every name is one letter

Beautifying restores shape, not names, so reading a minified bundle is its own small craft. The mangler only renames what's local; the things it can't touch are your most reliable landmarks. Beautify first, then work through these in order, and most vendor-script mysteries resolve without a single support ticket.

Search for string literals first. Error messages, URLs, and API paths survive minification untouched and lead you straight to the relevant function.
Follow the globals. Names like window.dataLayer or document.querySelector can't be mangled, so they anchor the logic around them.
Check the last line for a sourceMappingURL comment. If a source map exists, your browser's devtools can show the original code with real names.
Set breakpoints after formatting. Once the code has meaningful line numbers, stepping through it becomes practical.

Mistakes that waste an afternoon on unminified code

Most frustration with beautified output comes from expecting the wrong things of it. These are the traps worth knowing in advance.

Editing the beautified file and shipping it. Your fix disappears on the vendor's next release; patch at the source or pin the version instead.
Treating the output as the original source. Comments, types, and names are gone for good, so document what you learn as you go.
Pasting an entire two-megabyte bundle when one function is failing. Isolate the chunk around the error column first and format just that.
Confusing minification with obfuscation. A beautifier undoes the first in one click; deliberately obfuscated code stays hostile even when neatly indented.

Three habits that make vendor scripts less painful

When you adopt a third-party script, beautify it once and save the downloaded file next to your integration notes. On the next version bump, format the new file with the same indent and brace settings and diff the two; changelogs rarely tell the whole story.

Use devtools pretty-print while the debugger is open, and this tool when you want the formatted file outside the browser, for diffing, annotating, or sharing in a review. They're complements, not competitors.

And when you report a vendor bug, quote the beautified excerpt with line numbers. Support engineers respond faster to code they can read too.

Where the JS Beautifier ends and other tools begin

This page has one opposite and a few neighbors. The JavaScript Minifier reverses the trip, shrinking readable code for production, so together they cover both directions of the same workflow. When the thing you pasted turns out to be JSON, switch to the JSON Formatter, which validates while it formats and will catch the trailing comma a JavaScript formatter would silently accept.

For the rest of a widget's payload, the HTML Beautifier and CSS Beautifier do the same favor for markup and styles. Keep each language in its own formatter and the output stays trustworthy.