How to Pretty-Print Minified JavaScript

You open a production site’s dev tools to debug something, or someone sends you a .js file with no formatting whatsoever, and what you’re looking at is a single massive line — or a handful of lines — with every variable name shortened and every unnecessary character stripped. Minified JavaScript is great for production performance and completely unreadable for a human trying to understand or debug it.

Reading minified code by scrolling horizontally through one impossibly long line isn’t really reading it at all — you need it reformatted with actual line breaks and indentation before you can follow the logic.

What pretty-printing JavaScript actually involves

Minification strips whitespace, shortens variable names where safe, and removes anything not strictly necessary for the code to execute — all things that make files smaller and faster to load, but that also make the code visually impossible to follow. Pretty-printing (or “beautifying”) reverses the whitespace and formatting part of that process: it re-inserts line breaks at logical points, applies consistent indentation for nested blocks, and generally restores the code to a readable shape.

Importantly, pretty-printing doesn’t recover the original variable names that minification often shortens — that information is genuinely gone once minified. What you get back is correctly indented, readable structure around whatever variable names the minified code actually has, which is still a massive improvement for actually following the logic even if the names themselves are cryptic.

Why people get stuck here

• Minified code is a wall of characters, not readable text. Without line breaks and indentation, following nested logic (conditionals inside loops inside functions) is nearly impossible by eye.
• Variable names are often shortened beyond recognition. Pretty-printing restores structure but can’t restore meaningful names that minification already discarded.
• Debugging production issues sometimes means working with only the minified file. Source maps aren’t always available, leaving raw minified code as the only option for tracing a bug.
• Manually adding line breaks is impractical. Doing this by hand for anything beyond a few lines is far too slow to be a realistic option.

What a good JavaScript formatter looks like

Restores logical line breaks and indentation

The core job is turning a wall of code into properly structured, readable formatting that reflects the actual nested logic.

Offers indent style options

Being able to choose between spaces or tabs, and adjust indent width, matches the formatter’s output to whatever convention you’re working with elsewhere.

Processes the code locally

Since you might be pasting in proprietary or sensitive production code just to debug it, processing locally rather than uploading to a server matters.

Common mistakes to avoid

• Expecting pretty-printing to recover original variable names — it restores structure and readability, not information that minification already discarded.
• Trying to read minified code directly without reformatting first, which is far more error-prone and slow than it needs to be.
• Editing pretty-printed code and then trying to use it as a drop-in replacement for the original minified file in production, when the two serve very different purposes.
• Forgetting that pretty-printing is purely cosmetic — it doesn’t change what the code actually does, just how easy it is to read.

How to do it with the JavaScript Formatter

Online Tool Store’s JavaScript Formatter reformats minified JavaScript entirely in your browser.

1. Paste in your minified or poorly formatted JavaScript.
2. Choose your preferred indent style.
3. Get back properly indented, readable code.
4. Use the reformatted version to actually follow and debug the logic.

Because it runs locally, you can paste in production code you’re debugging without sending it to an external server.

Frequently asked questions

Will pretty-printing restore the original variable names from before minification?

No — minification often shortens variable names as part of the size-reduction process, and that information isn’t recoverable from the minified file alone. Pretty-printing restores readable structure (line breaks, indentation) but works with whatever variable names are actually present in the minified code.

Is pretty-printed code safe to use in production instead of the minified version?

Pretty-printed code is functionally equivalent to the minified version — it does the same thing — but it will be significantly larger in file size due to the restored whitespace, which is exactly what minification exists to avoid. Use pretty-printed code for reading and debugging, and keep the minified version for actual production delivery.

What’s the difference between pretty-printing and using source maps for debugging?

Source maps, when available, map minified code back to the actual original source files, including original variable names and file structure — a more complete debugging aid than pretty-printing alone. Pretty-printing is a fallback for when source maps aren’t available, giving you readable structure even without the original source information.

Final thought

Minification and readability are fundamentally at odds by design — pretty-printing doesn’t undo that trade-off, it just gives you a temporary, readable view of the same code so you can actually work with it.

Try the free JavaScript Formatter