JavaScript Beautifier_
Paste minified or one-line JavaScript and read it back with structure. Indentation, line breaks and spacing are restored; the code itself is untouched, so what comes out runs exactly as what went in did.
What no beautifier can give back is names. Minification renamed every local variable to a single letter and threw the originals away, so the shape of a program returns and its vocabulary does not — function a(b,c) stays function a(b,c) however it is laid out. Knowing that in advance saves a lot of squinting.
- Input
- JavaScript in any state — minified to one line, machine-generated, or written by someone with different habits from yours. JSX and modern syntax are handled.
- Output
- The same program with whitespace restored. Not a rewrite: the tokens are yours, only the space between them changes.
- Processing
- Reformatted in this tab. Source you paste into a formatter is often unreleased or from a client, and there is nowhere for it to go from here.
- Limits
- Whitespace only. Nothing is renamed, reordered, removed or modernised, and a syntax error survives the trip intact rather than being repaired.
- What minification destroyed is gone
- A minifier renames locals to single letters, drops comments, and discards the original names entirely — they are not stored anywhere in the output. Beautifying restores the layout and cannot restore the vocabulary. If a source map was published alongside the bundle, that is the only thing that brings names back, and it is a separate file you have to find.
Layout is recoverable, meaning is not
What survives minification and what does not
Minification does several things at once and only one of them is reversible. Whitespace and line breaks are removed, and a beautifier puts them back exactly. Comments are deleted, and they are gone. Local variables and function parameters are renamed to single letters, and the originals are not recorded anywhere in the file. Some minifiers also rewrite expressions into shorter equivalents — turning true into !0, collapsing if statements into conditional expressions — and those rewrites stay rewritten. You get a readable program that says what it does in an alphabet of one-letter names.
A beautifier is not Prettier, and the difference matters
Prettier parses your code into a syntax tree and prints it back from scratch, discarding every layout decision you made and applying its own. A beautifier adjusts the whitespace around the code that is there and leaves your structural choices alone. That is why people complain that a beautifier "ruins" hand-formatted code — it is doing something narrower and less opinionated than they expected. For a codebase you own, an opinionated printer is usually the right answer. For a file you have been handed and need to read once, this is.
Semicolons, and why the output can look surprising
JavaScript inserts semicolons where it thinks statements end, which means line breaks can carry meaning. A beautifier that moved a return onto its own line and left its value on the next would change what the program does — so a careful one never breaks in those positions, and the result is occasionally a long line where you expected a short one. If the output looks oddly reluctant to wrap somewhere, that reluctance is usually deliberate.
When the file has a source map
Look at the last line of the bundle. A comment reading //# sourceMappingURL=… points at a .map file, and if that file was actually deployed it contains the original names, the original file boundaries and often the original source in full. Opening the bundle in browser devtools with the map present gives you the real code rather than a tidied minification. Beautifying is what you do when the map is missing, which on production sites it usually is.
Reading a bundle you did not write
Most of what people paste here is somebody else's build output, and the useful approach is to stop trying to read it linearly. Beautify it, then search for the strings that cannot be minified — URLs, error messages, event names, API paths — because those are the only identifiers that survive intact, and they lead straight to the part you actually care about. The one-letter names around them will start to make sense from context far faster than reading from the top.
Paste, read the line counts, adjust
- 01Paste the JavaScript or upload a file. It reformats on every keystroke, so a one-line bundle becomes readable immediately.
- 02Watch the line counts: one line in and several thousand out is the normal result for a minified bundle, and the longest-line figure tells you whether anything is still unwieldy.
- 03Set a wrap width if very long lines remain. It only breaks where a break is safe, so some lines will stay long on purpose.
- 04Turn off "keep blank lines" when the input is machine-generated and its blank lines mean nothing.
A minified bundle you need to read once
A production script is doing something unexpected and there is no source map. Structure comes back; the names do not, which is the honest expectation to start with.
function a(b,c){return b&&c?b+c:!1}function a(b, c) {
return b && c ? b + c : !1
}A one-line snippet from a bug report
Someone pasted a fragment with all the newlines stripped by their chat client. Restoring the layout makes it reviewable in seconds.
if(x){doThing();}else{doOther();}if (x) {
doThing();
} else {
doOther();
}Inline script pulled out of a page
A script tag written with no formatting at all, or generated by a template. Beautifying gives it enough shape to see what it touches.
window.addEventListener("load",function(){var a=document.querySelectorAll(".x");for(var i=0;i<a.length;i++)a[i].hidden=!0})window.addEventListener("load", function() {
var a = document.querySelectorAll(".x");
for (var i = 0; i < a.length; i++) a[i].hidden = !0
})Code that arrived with the wrong indentation
A file written with tabs when your project uses two spaces, or the reverse. This changes the layout without touching anything else in the file.
function f() {
if (x) {
return 1;
}
}function f() {
if (x) {
return 1;
}
}What a minifier did, and whether it comes back
| What minification did | Reversible | Why |
|---|---|---|
| Removed line breaks and indentation | Yes | Whitespace between tokens carries no meaning, so it can be regenerated exactly. |
| Deleted comments | No | They are not in the file any more. Nothing can infer what they said. |
| Renamed locals to single letters | No | The original names were discarded. Only a source map preserves them. |
Rewrote true as !0 | No | That is a code change, not a layout change, and it still means the same thing. |
Collapsed if into ?: | No | Structural rewriting. A beautifier will not undo it, and undoing it would be a guess. |
| Dropped optional semicolons | Partly | They can be reinserted where the grammar allows, but the beautifier keeps the code as written rather than editing it. |
| Merged many files into one | No | File boundaries are gone unless a source map records them. |
The dividing line is whether the change touched whitespace or touched code. Only the first kind is a formatting decision, and only formatting decisions can be made again.
Reading someone else's JavaScript faster
- Look for the source map before beautifying. A
//# sourceMappingURLcomment on the last line means the real names may be one fetch away. - Search for string literals first. URLs, error messages and event names survive minification untouched, and they are the fastest route into a bundle.
- Beautify before diffing two builds. Two minified files differ on one enormous line; two beautified ones differ where the change actually is.
- Do not commit beautified vendor code back into a repository. It is derived output, it will be overwritten by the next build, and the diff noise is enormous.
- Use Prettier or your editor for code you own. A beautifier is for reading what you were given; an opinionated printer is for keeping what you write consistent.
What this does not do
It does not recover names
Minification discarded them. A beautified bundle is readable in structure and anonymous in vocabulary, and no tool can invent what was deleted.
It does not validate or fix your code
A syntax error goes in and comes out, reformatted. If the output looks wrong from a certain point onwards, that point is usually where the parser lost its footing.
It is not a deobfuscator
Deliberately obfuscated code — string arrays, control-flow flattening, encoded identifiers — is still obfuscated after formatting. Layout was never what made it unreadable.
Formatting is not permission
Being able to read a bundle says nothing about whether you may reuse what is in it. Minified code is still covered by whatever licence it shipped under.
Engine, syntax support and limits
- Engine
- js-beautify, the same library behind most editor "beautify" commands and the extension of the same name. Whitespace is adjusted around the existing tokens; nothing is reprinted from a syntax tree.
- Syntax
- Modern JavaScript including modules, classes, async and await, optional chaining, template literals and JSX. TypeScript annotations are not parsed and are left as written.
- Statement safety
- Line breaks are not introduced in positions where automatic semicolon insertion would change the meaning of the program, which is why some long lines stay long.
- Limits
- Input is refused above 8 MB; output past 2 MB is truncated for display while Copy carries the whole result.
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about beautifying JavaScript
Can a beautifier undo minification?
Only the whitespace half of it. Line breaks and indentation come back exactly; comments, original variable names, and any expression the minifier rewrote do not, because none of them is stored in the minified file. You end up with readable structure and single-letter names.
How do I get the original variable names back?
You need the source map. Check the last line of the bundle for a //# sourceMappingURL comment — if that .map file was deployed, browser devtools will show you the original source, names and file boundaries. If it was not deployed, the names are gone permanently.
What is the difference between a beautifier and Prettier?
Prettier parses the code and reprints it from scratch in its own style, discarding your layout decisions. A beautifier adjusts spacing around the code that is already there and keeps your structure. Prettier is for enforcing consistency in code you own; a beautifier is for making code you were handed readable.
Will beautifying change what my code does?
No. Only whitespace between tokens is altered, and JavaScript ignores that — with one exception the tool respects, which is that a line break in the wrong place can trigger automatic semicolon insertion. Breaks are not introduced in those positions, which is why the output sometimes keeps a line longer than the wrap width.
Why does the output still look unreadable?
Probably because it was obfuscated rather than merely minified. String arrays, encoded identifiers and flattened control flow survive formatting untouched, because layout was never what made them hard to read. Minification and obfuscation are different operations with different intentions.
Can I beautify TypeScript or JSX?
JSX yes — it is handled directly. TypeScript will be reformatted but its type annotations are not parsed, so unusual generic syntax can come out with spacing you did not intend. For TypeScript that you own, run Prettier with the TypeScript parser instead.
Should I commit beautified third-party code?
No. It is derived from a build you do not control, the next release overwrites it, and the diff against the original is unreadable. Beautify to read, keep the original in the repository.
Does my code leave the browser?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.