JavaScript Beautifier

Prettier reprints from a parse tree instead of re-indenting

The word “beautifier” undersells what happens here. A re-indenter reads your lines and adjusts the spaces at the front of each one. This page runs Prettier, version 3.9.4, which parses the code into a syntax tree, throws your original layout away entirely, and prints the tree again from scratch under its own rules.

The difference shows up immediately on minified input. Feed it this, all on one line:

function f(a,b){if(a>b){return a}else{return b}}const g=(x)=>x*2;let s="hi";

and the default settings return:

function f(a, b) {
  if (a > b) {
    return a;
  } else {
    return b;
  }
}
const g = (x) => x * 2;
let s = "hi";

Nothing there was salvaged from the input’s formatting, because the input had none. The line breaks, the spacing around operators and the semicolon that now closes return a all come from the printer, working out from the tree it built.

The cost of a real parser is that it refuses work it cannot understand, which is the subject of two sections further down.

Pasting code, picking a style, reading what comes back

1. Paste the code into the box above. A minified line, a fragment lifted from a bundle, a whole module or a TypeScript file with types are all fine.
2. Leave Language on Auto-detect (default), or pick JavaScript or TypeScript if you already know which one you have.
3. Set the layout you want with Indentation, Indent size (spaces per level) and Max line length, then decide on End statements with semicolons and Use single quotes instead of double quotes.
4. Click JavaScript Beautifier. The formatted code replaces the input box, and Copy to clipboard takes it; Process another clears everything and starts over.

Both number fields are clamped before Prettier sees them. Indent size lands between 1 and 8, maximum line length between 40 and 200, so a hand-edited value cannot produce something absurd.

Which options change your code and which only change its shape

Indentation, indent size and maximum line length are the shape controls. They decide where the code sits, not what it says. Set the maximum line length to 40 and a long call breaks apart:

const result = someFunction(
  argumentOne,
  argumentTwo,
  argumentThree,
  argumentFour,
);

Raise it to 200 and the same call stays on one line. Two details in that block are worth noticing, because they are the limits of calling these controls cosmetic. The split arguments picked up a trailing comma that the one-line version does not have, and choosing tabs would replace those leading spaces with tab characters. Both are layout conventions rather than edits to your logic, and both show up in a diff.

The remaining two controls really do rewrite tokens. Turning off semicolons removes them from statement ends and adds a protective leading semicolon where dropping one would be unsafe. Switching to single quotes swaps the quote characters around your strings, leaving the text between them exactly as it was. If your project has an opinion on either, set it here once rather than fixing the diff later.

Un-minifying gives back the shape, not the names

Restoring formatting to a bundled script genuinely works. Line breaks, indentation and spacing come back completely, and code that was an unreadable wall becomes something you can step through in a debugger.

What cannot come back is anything the minifier deleted rather than reformatted. Your descriptive identifiers were rewritten to a, b and c, and every comment was stripped, before the file reached the browser. No formatter reconstructs information that is no longer in the input. So this makes a minified file readable; it does not recover its source. When you are trying to work out what actually changed between two builds, format both and then compare them with the Text Diff Checker. Its default line view treats indentation as significant, so putting both sides through the same printer first is exactly what leaves only real changes to report.

Which parser answers when the code will not parse

With Language on Auto-detect the module tries Prettier’s JavaScript parser first and, if that throws, the TypeScript one. That order is what lets interface, type annotations and as casts format without you selecting anything.

It also decides whose complaint you see. Paste function { and leave the language on Auto-detect, and the message names the TypeScript parser’s reading of the problem, Identifier expected. (1:10), because that was the last attempt to fail. Set Language to JavaScript explicitly and the same input reports Unexpected token (1:10) instead. Same character, same column, two parsers describing it differently. If an error reads oddly, forcing the language you actually wrote often produces a clearer one.

When the thing you pasted is not JavaScript

A syntax error is usually a real syntax error, but not always. The most common false alarm is pasting a bare JSON document, which looks close enough to an object literal to fool the eye. As a statement it is not valid, and the tool reports something like a missing semicolon at column 5 rather than anything about JSON. Send that to the JSON Formatter & Validator instead, where the same text parses cleanly.

Stylesheets are the other frequent mismatch: this page loads only the JavaScript and TypeScript parsers, so CSS never had a chance, and the CSS Minifier & Formatter has a beautify mode for it. Markup has the same story, and there is a small twist worth knowing if you work on pages rather than modules. The HTML Minifier & Beautifier deliberately copies the contents of every script element out untouched, so the code embedded in a page stays exactly as you wrote it there. Format it here first, then paste it back.