Why minified code is hard to read
Before JavaScript is sent to a browser it is often minified: comments and line breaks are removed and everything is packed onto one or a few very long lines. That saves bytes but makes the file almost impossible to read. A beautifier does the opposite and spreads the code out again.
// Minified
function a(b){return b.map(function(c){return c*2})}var d={x:1,y:[2,3]};
// Beautified
function a(b) {
return b.map(function (c) {
return c * 2
})
}
var d = {
x: 1,
y: [2, 3]
};How this page is set up
This page starts with settings that suit compressed code: a 4 space indent, the old line breaks ignored, and each property of an object on its own line. You can change any of them. The same engine drives the JavaScript formatter, which starts with gentler settings for code you wrote yourself.
What a beautifier cannot bring back
- Names. Minifiers shorten variable and function names to one or two letters. A beautifier cannot know what they were.
- Comments. They are deleted when code is minified.
- The original layout. Your old line breaks and blank lines are gone, so the layout is rebuilt from the code.
If the project published a source map (a file ending in .map), a browser can show the original names and files. Otherwise a beautifier is the best you can do.
Reading code in the browser
Browser developer tools can also beautify a file. In the Sources panel, open a script and press the pretty print button, shown as a pair of curly braces. This tool is handy when you have the code as text, for example from a file, a bookmarklet or a network response.
Semicolons and line breaks
JavaScript can end a statement at a line break, so some minified code has no semicolons. The beautifier respects this and starts a new line where the original had one, rather than guessing. It never adds or removes semicolons, so the meaning stays the same.
Once the code is readable you can read it with line numbers using JavaScript pretty print, or shrink it again with the JavaScript minifier.