JavaScript & TypeScript Formatter

What is a JavaScript formatter?

Somebody hands you a file. It came out of a build, or out of a CMS field, or off a branch where the author had their editor set up differently, and it arrives as one long line with no space around the operators and no visible brace depth. You can read it. You read it slowly, holding the nesting in your head, spending the time on layout rather than logic. A formatter prints that file again with consistent indentation, breaks in defensible places, and one style end to end.

This page runs Prettier, the formatter most JavaScript projects already have in their repository, loaded into your browser and executed there. Choose JavaScript, TypeScript, JSX, or TSX, paste code into the left panel, and the reprinted version lands opposite before you have finished pasting. Five settings control the house style: indent width, semicolons, single or double quotes, where trailing commas are allowed, and how wide a line may get before Prettier breaks it apart. Change any of them and the output rebuilds immediately, which is a fast way to see what a setting does to real code before you argue for it in a config file.

When to use it

The clearest case is code you did not write and cannot format where it lives. A vendor script pasted into a tag manager. A handler stored in a CMS text field with no editor behind it. A function copied out of a ticket with whatever indentation survived the paste. Output from a generator nobody has opened. A chunk lifted out of a built bundle in devtools. None of those has a repository, a config, or format-on-save, so the only way to make one readable is to run it through something.

The second case is a disagreement. Two people indent differently, one puts the operator at the end of the line and the other at the start, and review becomes a conversation about neither person's code. Handing the decision to a tool ends that, and ends it in a way nobody has to keep enforcing, because the same input produces the same output whoever runs it. Try a candidate style here on a real file from your project and see whether the team can live with it. Shorter path than committing a config and finding out over three pull requests.

Formatting and minifying sit at opposite ends of the same pipeline. Prettify to read, minify to ship. Arrived with a compressed file you need to understand? This is the right page. Have readable code that needs to fit inline in a page? The JS Minifier does that pass with Terser. Sending a file through the minifier and back through this formatter will not return your original text, since minification drops comments and renames locals for good, but it does give you something a person can follow.

How this tool works

Prettier throws your formatting away and prints the file again from scratch. It parses the source into a syntax tree, keeps what carries meaning (comments, and whether you left a blank line between two statements), and discards the rest of your layout. Then it builds an intermediate document of groups, each with places where a break is permitted, and prints it while measuring every group against your print width. A group that fits stays on one line. One that does not breaks at its permitted points, and its children get measured again. That is why a long method chain comes back as four indented lines, and why the output is identical whether the input was crammed onto one line or spread over thirty.

Printing from a tree is what makes it safe. Whatever comes out parses to the same tree that went in, so braces you omitted may reappear and an argument list may be broken up, but the operations and their order survive. A few normalisations touch a literal rather than the structure. A number written as 0.50 comes back as 0.5. Quotes flip to the style you chose unless flipping would add an escape, so with single quotes selected the string "it's here" keeps its double quotes.

The four language buttons are load-bearing. JavaScript and JSX go to Prettier's babel parser, TypeScript and TSX go to its typescript parser, and both hand their tree to the estree printer, which is why that printer loads alongside every parser. The TypeScript pair is separated by file extension, which resolves an ambiguity nothing else can. In a .ts file, const f = <T>(x: T) => x is a generic arrow function. In a .tsx file the same characters open a JSX element and the parser rejects the line. Choosing TSX for a component and TypeScript for a plain module is the difference between output and a parse error.

Prettier is around 2 MB all told, so it is fetched from a CDN on demand rather than bundled here, and only the parts your language needs are fetched. JavaScript pulls the core (about 78 KB), the babel parser (about 320 KB), and the estree printer (about 200 KB). The TypeScript parser is the large one at roughly 890 KB, requested only if you pick TypeScript or TSX. The toolbar says what it is waiting for, switches to "Prettier ready", and formats whatever you typed while it downloaded. Everything after that runs in your tab, and a file that will not parse comes back as the parser message with a line and column rather than as output.

Examples

• A function compressed onto one line

  Input

  function total(items){let s=0;for(const i of items){if(!i.active)continue;s+=i.price*i.qty}return s}

  Output

  function total(items) {
    let s = 0;
    for (const i of items) {
      if (!i.active) continue;
      s += i.price * i.qty;
    }
    return s;
  }

  JavaScript, default settings. Nothing was renamed and no statement moved. Prettier ends its output with a newline, which the examples on this page leave off.

• Semicolons off, single quotes

  Input

  const user = {name: "ada", role: "admin"};
  export default user;

  Output

  const user = { name: 'ada', role: 'admin' }
  export default user

  Semicolons set to "Leave them off", Quotes set to Single. Both trailing semicolons go and both strings flip. Prettier still emits one where omitting it would change meaning: a line starting with an opening bracket, parenthesis, or backtick gets a leading semicolon, so the line above is not read as a call or an index.

• Print width decides where a signature breaks

  Input

  export function scheduleDelivery(orderId, warehouseCode, carrierService, requestedDate) { return queue.push({ orderId, warehouseCode, carrierService, requestedDate }); }

  Output

  export function scheduleDelivery(
    orderId,
    warehouseCode,
    carrierService,
    requestedDate,
  ) {
    return queue.push({ orderId, warehouseCode, carrierService, requestedDate });
  }

  Print width 80. That signature runs to 89 characters on one line, so the parameter list breaks and each parameter takes a line. Set print width to 120 and the signature comes back intact.

• Trailing commas on a broken-up argument list

  Input

  registerQueueHandler(inboundQueueName, processInboundMessage, retryPolicyOptions);

  Output

  registerQueueHandler(
    inboundQueueName,
    processInboundMessage,
    retryPolicyOptions,
  );

  Trailing commas set to All, print width 80. The comma after the last argument appears only because the call was too wide for one line. Switch to ES5 or None and the same output arrives without it, since a trailing comma in a call is ES2017 and invalid in ES5.

• TypeScript at four-space indentation

  Input

  interface Invoice{id:string;total:number;lines:Array<{sku:string,qty:number}>}
  export function subtotal(inv:Invoice):number{return inv.lines.reduce((n,l)=>n+l.qty,0)}

  Output

  interface Invoice {
      id: string;
      total: number;
      lines: Array<{ sku: string; qty: number }>;
  }
  export function subtotal(inv: Invoice): number {
      return inv.lines.reduce((n, l) => n + l.qty, 0);
  }

  TypeScript, tab width 4. Interface members get a line each, and the comma inside the inline object type is normalised to a semicolon, the form Prettier prints for type members.

• A missing bracket

  Input

  const totals = items.map(i => i.price;

  Output

  Line 1, column 38: Unexpected token, expected ","

  A file that does not parse cannot be printed, so you get the parser's complaint and the position it gave up at. Column 38 is the semicolon, which is where the parser noticed; the real mistake is the missing closing parenthesis before it. A parser stopping downstream of the real error is normal, and the position is still the right place to start reading.

Frequently asked questions

• How do I format JavaScript code online?

  Pick the language at the top of the page and paste your code into the left panel. The reprinted version shows up beside it while you are still pasting. Nothing to click, nothing to upload. Change any of the five settings and the output rebuilds against them. Copy Output takes the formatted code; Clear empties both panels.

• Can formatting change what my code does?

  No, because the output is printed from the tree the parser produced, so it parses back to that same tree. The setting worth understanding is semicolons. With them off, JavaScript falls back on automatic semicolon insertion, and a line beginning with an opening parenthesis, bracket, or backtick would attach itself to the line above as a call or an index. Prettier adds a leading semicolon to those lines. The style is safe when a formatter produces it and risky when someone deletes semicolons by hand.

• Semicolons or no semicolons, trailing commas or not?

  Neither choice affects how the code runs. Semicolons are about how much you want to think about automatic semicolon insertion; leaving them on means never thinking about it. Trailing commas are about diffs. With All or ES5, adding an entry to a multi-line list touches one line instead of two, so the diff shows your addition rather than your addition plus a comma appearing above it. ES5 puts the comma only where ES5 allows it, in objects and arrays. All extends it to parameters and call arguments, which needs ES2017 or a transpiler.

• Does print width guarantee my lines fit in 80 columns?

  It does not. Print width is what Prettier measures against while deciding whether a group fits, and some things cannot be broken. A long string literal, a URL, a deep import path, or one long identifier runs past it because there is nowhere legal to put a break. Other constructs break for reasons unrelated to width: a chain of three or more calls splits across lines whether or not it would have fit. It shapes the output rather than capping it.

• Will this find problems in my code?

  No. This formats and does nothing else. It will not tell you a variable is unused, an await is missing, a promise has no catch, or a comparison uses the loose operator. Those belong to a linter such as ESLint, which analyses what code means rather than how it is printed. Most projects run both, the formatter owning layout and the linter owning correctness. A file that formats cleanly here can still be full of bugs.

• Should I prettify or minify my JavaScript?

  Prettify what you are about to read, minify what you are about to serve. Formatting makes a file larger and easier to follow, which is what you want in an editor, in review, or when working out what a script someone sent you does. Minification makes it smaller and unreadable, which is what a browser wants. The source of truth stays the formatted version in your repository. Our JS Minifier handles the other direction.

• Our team keeps relitigating formatting. Can you make that stop?

  That argument usually points at missing plumbing rather than missing agreement. A repository with no automated format check drifts whatever was decided in a meeting, because every editor ships its own defaults and nobody notices until a pull request is four hundred lines of moved braces with six lines of logic inside. Zinc Online Solutions puts in the boring half: a committed config, a hook that formats on commit, a CI job that fails on unformatted files, and one reformatting commit recorded so blame can skip it and your history stays legible. Tell us which repositories are involved and what your pipeline runs today.