Code Formatting Explained: Beautifiers, Minifiers & Style

You paste a JavaScript file into your editor and get one 40,000-character line. This guide covers why that happens, what a beautifier can honestly do about it, and which formatting choices — indent size, brace style, line wrap — actually matter once you're producing readable code.

What code formatting is

Source code carries two layers: what it does (semantics) and how it reads (layout). The layout layer — indentation, line breaks, spacing around operators, brace placement — exists purely for humans. The interpreter or compiler throws it away, or in JavaScript's case, mostly ignores it. Formatting is the craft of choosing that layout so structure is visible at a glance: nesting depth shows in the indent, related statements group into lines, function boundaries announce themselves.

Because layout is meaningless to machines, tooling can transform it freely in both directions. Minifiers compress it away to shrink downloads. Beautifiers restore it to restore comprehension. Neither touches behavior.

Why minified code looks like noise

A minifier's job is byte reduction. It deletes every space and newline the grammar allows, renames every local variable to one or two characters, strips comments, collapses what it can, and drops code it can prove is unreachable. The result is fast to download and miserable to read. Here's a realistic taste — 110 characters, one line:

function add(a,b){return a+b}const calc={add:function(x,y){return x+y;},mul:(a,b)=>a*b};console.log(add(2,3));

Beautified with js-beautify at 2-space indent, the same program becomes 10 lines and reads like code again:

function add(a, b) {
  return a + b
}
const calc = {
  add: function(x, y) {
    return x + y;
  },
  mul: (a, b) => a*b
};
console.log(add(2, 3));

The character count grows about 35% in this small example. On real bundles the reverse trip is more dramatic — a 500 KB library minified from a readable source gains hundreds of lines back when beautified, because the minifier squeezed out every skippable byte.

What a beautifier can't recover

This is the part every guide should say out loud: beautify is not unminify. Three losses are permanent:

• Variable names. totalWithTax became t in the minifier and no tool can guess it back.
• Comments. Deleted outright. The "// why we do this weird thing" knowledge is gone.
• Dead code. If the minifier removed an unused function, beautifying the bundle won't resurrect it.

So a beautifier is a reading aid for artifacts you don't own — production bundles you're debugging, a suspicious script, a copied snippet. For code you do own, format the original source with an editor plugin so nothing is lost in the first place.

The style options worth knowing

Formatting engines expose a lot of knobs. Four of them explain almost all the visible differences between two teams' code:

Two honorable mentions: end_with_newline (POSIX-friendly files end with a newline) and space_after_anon_function, which decides between function() and function () — the single most religious whitespace argument in JavaScript history.

Brace styles, in one paragraph each

Collapse puts the opening brace on the statement line. It's compact, it's the C-family default going back to K&R, and it's what most style guides ask for. Expand (Allman) puts every brace on its own line; vertical alignment makes block boundaries pop, at the cost of screen real estate. End-expand moves only closing braces to their own lines, and none leaves braces exactly where they were — useful when you're tidying indentation around hand-written layout you don't want perturbed.

Prettier vs js-beautify

Both format JavaScript; they differ in philosophy. Prettier is opinionated — few options, one canonical output, and it reformats whole files on save so style arguments end. js-beautify is configurable — the four options above plus more, permissive about existing layout, and lighter weight, which is why it's been the engine inside editor beautify plugins since long before Prettier existed. For CI-enforced consistency on a team codebase, Prettier is the standard answer. For "make this third-party blob readable right now," js-beautify is exactly the right tool.

How to choose settings that stick

1. If a lint config or style guide exists at work, mirror it — formatter and linter fighting each other is worse than either.
2. No config? Use 2-space indent and collapsed braces for JavaScript. Nobody will be surprised.
3. Set end_with_newline when files go through Unix tooling; diffs stay clean.
4. Only add wrap_line_length if your team actually reviews on narrow screens; wrapping has a reflow cost on later edits.

Then stop tuning. The point of a formatter is that nobody thinks about formatting again.

Formatting beyond JavaScript

The same minify/beautify cycle hits everything tree-structured. JSON APIs ship minified; a formatter restores it (our JSON formatter also validates while it's at it). SQL squeezed into one line for logging comes back to life with indentation — the SQL formatter handles joins and subqueries. XML, YAML, HTML all have the same story. The general principle holds across every one of them: formatting is reversible, minification's name-shortening is not, and the best time to make code readable is before it ships minified.

Frequently Asked Questions

Related Tools