Developer Tools·4 min read

How to Unminify JavaScript and Read Minified Code

Minified JavaScript is written for machines: every space removed, every 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 tool 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, paste the minified source into the Input pane, and click Beautify. The tool runs js-beautify in your browser and rewrites the code with a two-space indent, one statement per line, and braces placed where you'd expect them. Click Copy and the readable version is yours. The Try sample button loads a compressed one-liner if you want to see the effect before pasting your own file. Nothing gets uploaded, which matters when the script belongs to a client or contains keys you haven't audited yet.

The output follows familiar js formatting conventions: blocks indent with their nesting depth, operators get breathing room, and long chained calls break onto separate lines. Behavior stays identical, 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("Toolora");

After one click, 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("Toolora"); 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 minified bundles when every name is one letter

Beautifying restores shape, not names, so reading minified bundles is its own small craft. The mangler only renames what's local; the things it can't touch are your best 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 result next to your integration notes. On the next version bump, format the new file 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 JS 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.