JavaScript Formatter

JavaScript ignores whitespace almost everywhere. A function written as one 300-character line and the same function spread over fifteen lines are identical to the engine — both parse to the same syntax tree and run at the same speed. Formatting is entirely for the reader. It takes code whose structure is buried in a wall of text and puts that structure back on the screen: one statement per line, consistent indentation for nesting, and line breaks chosen by the same rule every time rather than by whoever typed it.

1function total(items,tax){const sum=items.reduce((a,i)=>a+i.price*i.qty,0);if(!tax)return sum;return sum*(1+tax)}2 3function total(items, tax) {4  const sum = items.reduce((a, i) => a + i.price * i.qty, 0);5  if (!tax) return sum;6  return sum * (1 + tax);7}

Nothing changed except whitespace. The second version runs the same and returns the same value — but you can see at a glance that there are three statements, one early return and one arrow function, and you could point at the line you wanted to change.

This tool works the way a real formatter has to: the file is parsed into a syntax tree and printed back out from that tree. It does not rearrange text with pattern matching, which is why it can be trusted with a five-thousand-line file. If the code cannot be parsed, nothing is printed — you get the error instead of a guess.

Everything here runs in your browser. The code people paste into a formatter carries endpoints, internal names and occasionally a key that should have been an environment variable, so nothing is uploaded, stored or logged.

Because inconsistent formatting costs attention on every single read, and reading is what people do with code. It also hides the specific mistakes JavaScript is prone to — a callback closed one brace early, a promise chain that silently returns nothing, an if whose body was never braced.

• Reviews stop being archaeology. A reviewer can see the shape of a function — how deep it nests, how many branches it has, where it returns — without rebuilding it in their head first.
• Diffs shrink to the actual change. With one statement per line and predictable breaking, adding an argument is a one-line diff, in a pull request or in a diff checker. Without it, reformatting noise buries the change nobody can then find.
• Bundled code becomes readable.Code pulled from a browser’s Sources panel, a CDN or a build output arrives on one line. Formatting is the first step to understanding any of it.
• Nesting stops being invisible. Four levels of callback look much like two until they are indented. Depth on the screen is depth in the program, and it is the most reliable signal that a function needs splitting.
• Teams stop arguing about style. One agreed set of options, applied by a tool, ends the discussion about semicolons permanently.
• Syntax errors surface immediately. A formatter has to parse before it can print, so it tells you about the unclosed brace on line 91 the moment you paste rather than when the build fails.

Everything a current engine runs, through ES2025, plus the whole of TypeScript and JSX. Two parsers are available — JavaScript and TypeScript — and both accept JSX; the difference is only whether type syntax is allowed as well. Leave detection on and the language is read off the source, or choose one in the options.

Indentation

Two spaces, four spaces or tabs. Indentation means exactly one thing — this is inside that — so it follows the syntax tree and nothing else. A block, an object literal, a JSX child and a chained call each indent from wherever they opened, and the closing character returns to the level of the line that opened it.

Quotes

Single or double, applied consistently. Whichever you choose, a string containing that character takes the other one instead, so nothing ever has to be escaped: "it’s" stays in double quotes even when the file is otherwise single-quoted. Template literals are never converted, because a template literal is a different thing from a string.

Semicolons

Always, or omitted. Omitting them is safe here because it is done by the printer rather than by deleting characters: a line that begins with [ or ( keeps a leading semicolon, which is what stops the line before it being read as an index or a call.

1const a = 12const b = [1, 2]3;[b].forEach((x) => x)   // without the ; this reads as b[...]

Line width

Adjustable from 40 to 200 characters, and it is a target rather than a limit. The printer fits what it can within the width and breaks at the outermost sensible point when it cannot, so an argument list collapses onto one line if it fits and expands one-per-line if it does not. A long string or a long identifier still runs past it — breaking those would change the code.

Import organisation

Sorting reorders the run of import statements at the very top of the file: packages first, then scoped packages, then aliased paths such as @/components, then relative paths, each group alphabetical.

1import { useState } from "react";2import { z } from "zod";3import { Button } from "@acme/ui";4import { formatDate } from "@/lib/date";5import { Header } from "./header";

Only that leading run moves. An import further down the file stays exactly where it is, because moving it could change the order in which side effects run. Unused imports are not removed either: knowing an import is unused means resolving every name through every scope, which is a type checker’s job, and getting it wrong deletes working code.

Syntax highlighting

Keywords, class names, function names, JSX tags, strings, template literals, regular expressions, numbers, operators, decorators and comments each get their own treatment, in both panels and in both light and dark themes. Blocks fold from the gutter, and matching brackets are marked as you move through them. Colouring a pattern is as far as it goes, though — to find out what one actually matches, the regex tester runs it against sample text.

Validation

Parsing is validation, so it comes free. When the parser stops, you get the message, the line, the column, a caret pointing at the character and a note about what usually causes it — and the location is a button that takes you there.

• Missing brackets, braces and parentheses, reported at the point the parser could no longer make sense of what followed.
• Unterminated strings, template literals and comments — the most destructive class of error, because everything after the opening character is being read as something it is not.
• Unexpected tokens, which is what a stray comma, a doubled operator or a keyword in the wrong place produces.
• Malformed imports and exports, including an import with no specifier and an export of something that was never declared.

You will only ever see one error at a time, and that is deliberate: a parser stops at the first thing it cannot read, so everything after that point is unparsed rather than wrong. Listing seventeen errors caused by one missing brace would mean inventing sixteen of them.

Make formatting a decision nobody makes

The value of consistent formatting is not that any particular style is better — it is that a reader stops noticing style at all. Agree on a set of options once, apply them with a tool, and put that tool in the commit hook so the question never reaches a code review. A team that has stopped discussing semicolons has bought itself real time.

Write functions that fit on a screen

A function you can see all of is a function you can reason about. Prefer early returns to nested conditionals, give the intermediate value a name instead of chaining six calls together, and take the deeply indented block out into its own function the moment the indentation starts running away.

1function price(item, user) {2  if (!item) return 0;3  if (!item.available) return 0;4  if (user?.plan === "pro") return item.price * 0.8;5  return item.price;6}

Organise modules around one idea each

A module should be describable in a sentence without the word “and”. Export what callers need and keep the rest private; a file with twenty exports is usually several files. Prefer named exports to default ones — they survive renaming, autocomplete finds them, and a search for the name finds every use.

Name things for the person who reads them next

camelCase for variables and functions, PascalCase for classes and components, SCREAMING_SNAKE_CASE for module-level constants. Name a boolean as a question — isActive, hasAccess — and a function for what it does rather than how it does it. A single-letter name is fine in a two-line callback and nowhere else.

Comment the why, let the code carry the what

A comment restating the line below it is noise that goes stale. A comment explaining the business rule behind an odd-looking condition, or the bug that a workaround exists for, is worth more than the code around it. Formatting handles the what; only you can supply the why.

Write for the next change, not this one

Code is written once and read for years. Prefer const until you need let, prefer explicit over clever, and treat the first version of anything as a draft that somebody unfamiliar will have to edit under time pressure.

They are opposites, and both are on this page. A formatter makes code easier for a person to read. A minifier makes it smaller for a browser to download. You format the code you keep and minify the copy you ship, and you never edit the minified copy by hand.

1// formatted — 4 lines, 130 characters2function total(items, tax) {3  const sum = items.reduce((a, i) => a + i.price * i.qty, 0);4  return tax ? sum * (1 + tax) : sum;5}6 7// minified — 1 line, 82 characters8function total(t,c){const e=t.reduce((t,c)=>t+c.price*c.qty,0);return c?e*(1+c):e}

Notice what the minifier did and did not do. It removed the whitespace and renamed the parameters and the local, because those names are invisible from outside the function and shortening them saves real bytes across a whole bundle — it is why a production stack trace points at t and c, and why source maps exist. It left total alone, because something outside might call it by that name.

Minifying here is deliberately conservative in one respect: nothing declared at the top level is renamed or removed. A build tool minifying a finished bundle knows an unexported function has no callers and can delete it. This page has a fragment you pasted, and watching an unused class vanish would be alarming rather than helpful. So dead-code removal and renaming apply inside functions, and the top level is left alone.

One genuine limitation: TypeScript and JSX cannot be minified, here or anywhere. Both have to be compiled into JavaScript before minification means anything, because neither is what an engine runs. Format the TypeScript, compile it with tsc or your bundler, and minify what comes out.

And in real projects, minification is not something you do by hand at all — it is what your bundler does on the way to production, with source maps, tree shaking and code splitting alongside it. The button here is for the times you want to see what a snippet costs, or to check that something still works once the names are gone.

The same tool, reached for at different moments. Every one of them starts with code that arrived in a state nobody chose.