JavaScript formatter

What it does

Beautifying reverses a build. Minified bundles, one-line handlers, code pasted out of a browser console — all of it goes in shapeless and comes back with one statement per line and a fresh indent at every block.

function shipping(n){if(n>=75){return 0}else if(n>=30){return 3.95}return 5.95}

function shipping(n) {
  if (n >= 75) {
    return 0
  } else if (n >= 30) {
    return 3.95
  }
  return 5.95
}

Modern syntax is handled: arrow functions, classes and private #fields, optional chaining, nullish coalescing, template literals, async and await, generators, and ES module import and export.

The options

What the checker finds

It is a structural check, not a linter and not a parser. It reads the file the way the minifier does — tracking strings, template literals, regular expressions and comments — and reports the three faults that make a file fail to load at all:

• Unbalanced brackets. Every {, ( and [ that is never closed, reported at the line it opened on rather than at the end of the file.
• Mismatched brackets. A { closed by a ], naming both lines.
• Unterminated literals. A quote or backtick that never closes, and a /* block comment with no end — which silently swallows everything after it.

For real static analysis — unused variables, shadowed names, accidental globals, promises you forgot to await — you want ESLint. It runs in your editor and knows what your code means, which no browser-side checker can.

Reading minified code

Beautifying a production bundle makes it readable, and it will not make it comprehensible. Minifiers rename local variables to single letters, and that cannot be undone — the original names are gone from the file.

What survives: string literals, property names on objects you did not create, imported module names, and the structure of the code. That is usually enough to work out what a function does, which is what you were after.

If a source map is published alongside the bundle — look for a //# sourceMappingURL comment at the end — your browser's devtools will show you the original source with real names, which is far better than anything a beautifier can reconstruct.

Formatting in your own editor

For code you work on regularly, this should happen on save and never be a decision anyone makes.

npm install --save-dev prettier
npx prettier --write "src/**/*.js"
npx prettier --check "src/**/*.js"     # fails the build if anything is unformatted

Prettier is the standard across the JavaScript ecosystem, and it is better than this page for code you own: it understands JSX, TypeScript and your framework's templates, and it is configured per project so everyone's output matches.

This page is for the cases with no project — a snippet from a colleague, a file you are inspecting on someone else's machine, a bundle you want to read, or code you would rather not paste into a website that uploads it.

A note on how this is built

Beautifying JavaScript properly means understanding the grammar, and the hardest part is the ambiguity of / — it starts a regular expression in one context and divides in another, and telling them apart needs to know what came before. Getting every case right takes years of bug reports.

So the beautifier here is js-beautify, which has had those years and is MIT licensed. It is a file your browser downloads once and then runs locally — nothing is sent anywhere, exactly as with every other tool on this site. The minifier on the minifier page is written here, and that page explains why it works the way it does.

Questions about this tool

Related tools

Learn the why, not just the how

Longer reading on formatting, indentation and minification.