TypeScript Beautifier & Formatter

Why a JavaScript beautifier breaks TypeScript

Most online TypeScript formatters run js-beautify underneath. That library tokenizes JavaScript, and TypeScript reuses characters JavaScript already assigned a meaning. The angle brackets in Map<string, number> look like less-than and greater-than to a JavaScript tokenizer, so they get padded like comparison operators. Worse, an arrow function with a return type ends in > followed by =>, and the tokenizer reads >= as a single operator. Here is the same line through both:

const load = async (id: number): Promise < User | null >= > {const r = await fetch(`/api/${id}`);return r.ok ? r.json() : null};

const load = async (id: number): Promise<User | null> => {const r = await fetch(`/api/${id}`);return r.ok ? r.json() : null;};

The earlier version of this page shipped the js-beautify path. Testing generics, optional properties and mapped types produced output with opts ? : {} and [K in keyof T] - ? :, both of which fail tsc. So the page now runs Prettier's own TypeScript parser and printer in the browser. The trade is about 1.2 MB of script on first visit, cached after, against output you do not have to repair by hand.

Construct by construct, what comes back

Every row below was pasted through this page at the default settings. The left column is the compressed input, the right is what the printer returns.

Two behaviors surprise people the first time. Enum members and object literals that fit within print width stay on one line only if they were written on one line and contain no newline after the opening brace. Put a line break after { and the printer keeps the object expanded regardless of width. And angle bracket assertions like <number>value format fine here because the page uses the plain TypeScript parser. In a real .tsx file that syntax is a JSX tag and tsc rejects it, so use value as number in React code.

The settings panel is a .prettierrc editor

Each control above maps one to one onto a Prettier option, and the config box under the output rewrites itself as you change them. The defaults on this page are Prettier's own defaults: two space indent, 80 column print width, double quotes, semicolons on, trailing commas everywhere including function parameters. Teams coming from older codebases most often flip three of them:

• Single quotes. Sets singleQuote: true. Strings containing a single quote still print with double quotes to avoid escaping, so a few lines will look inconsistent. That is intended.
• Print width 100 or 120. Widens before the printer breaks a call or a union across lines. 80 fits two files side by side on a 1440px laptop screen. 120 is common in Angular projects.
• Trailing commas ES5. Keeps the comma after the last array element and object property but drops it after the final function parameter. Pick this when you compile for a target older than ES2017 or when a linter rule complains about parameter commas.

Copy the config, save it as .prettierrc at the repo root, and npx prettier --write "src/**/*.ts" produces byte-identical output to this page, as long as the repo pins Prettier 3.3. A newer major or minor release can print a handful of constructs differently.

A syntax error stops the format instead of guessing

Because the input goes through a real parser, an invalid file does not get a best-effort reflow. It returns the parser's message and position, and the source pane scrolls to that line. Paste const x: = 5; and the panel reports Type expected (1:10). This is stricter than js-beautify, which reindents anything you hand it, and it is also the reason the formatted pane never contains code that the compiler would reject on syntax alone.

The parser checks syntax, not types. Assigning a string to a variable declared number formats without complaint. Missing imports, unknown identifiers and wrong argument counts all pass. Run tsc --noEmit for those.

Where this page stops

• First load is heavier than a regex formatter. The TypeScript parser plugin alone is 880 KB uncompressed, and the three scripts together pass 1.1 MB. On a slow connection the Format button stays disabled for a few seconds while they download. They cache after that.
• Files above roughly 300 KB stall the tab. Formatting runs on the main thread. A 5,000 line file takes about 1.3 seconds on a laptop, and 20,000 lines takes six seconds during which the page does not respond. Phones are slower still. Split generated code before pasting.
• No plugins. Import sorting, Tailwind class ordering and Svelte or Astro parsers all come from separate Prettier plugins, and none are loaded here. Imports keep the order you wrote them in.
• Not for Angular templates or Vue SFCs. The parser reads .ts and .tsx. A component's inline HTML template is a string to this page and gets left alone. The Angular formatter handles the template half.
• No .prettierrc import. You set options with the controls. Pasting an existing config file is not supported, though the seven options here cover what most configs set. Options not exposed keep their Prettier defaults: useTabs follows the indent picker, endOfLine is lf, quoteProps is as-needed.
• Nothing uploads. Your source never leaves the tab. That also means no share link and no history. Refreshing clears both panes.

Moving the same rules into the repo

An online formatter fixes one file. The repo needs the same output on every commit, from every editor. Three steps get there:

1. Save the config box above as .prettierrc and add Prettier as a dev dependency: npm i -D prettier@3.3.3.
2. Turn on format on save. VS Code needs the Prettier extension and "editor.defaultFormatter": "esbenp.prettier-vscode" in .vscode/settings.json. WebStorm ships Prettier support under Languages, then JavaScript, then Prettier.
3. Add prettier --check . to CI so an unformatted file fails the build rather than reaching review. A pre-commit hook through lint-staged catches it earlier still.

Once that is in place this page is for the cases outside the repo: a snippet from a chat, a file from a client without a config, or checking what a setting change would do before you commit it.