JavaScript Formatter

Paste a blob of minified or badly indented JavaScript and get back clean, readable code formatted with the same rules editors use. Choose tabs or spaces, single or double quotes, semicolons or not, trailing commas in ES5 or all. Handles modern syntax, optional chaining, nullish coalescing, JSX, TypeScript, top-level await.

How to format JavaScript

  1. 1

    Paste the source

    Any valid JS, JSX or TypeScript. The parser picks the dialect from the syntax.

  2. 2

    Set your preferences

    Indent size, tabs vs spaces, quote style, semicolons, print width, trailing commas.

  3. 3

    Format

    The tool runs a Prettier-compatible pass and outputs the formatted result.

  4. 4

    Copy the output

    One-click copy, or download as a file. The original indentation is discarded, not layered on top.

Style options

Option Values Default
Indent tab, 2, 4 2 spaces
Quote style single, double double
Semicolons always, never always
Print width 60 - 120 80
Trailing commas none, es5, all es5
Arrow parens always, avoid always
Bracket spacing true, false true
JSX single quote true, false false

Why formatting matters

Formatting is not cosmetic, it is about reducing cognitive load. A consistently formatted codebase lets reviewers focus on the logic change, not on hunting for a misplaced brace.

  • Bike-shedding ends once a project adopts a formatter. git diff shows the real change, not indentation debates.
  • Pre-commit hooks (with tools like Husky + lint-staged) auto-format staged files before they are committed.
  • Editor integration (VS Code, WebStorm) runs the same rules on save.

What formatting does not do

  • It does not lint. Style rules (no-unused-vars, eqeqeq) are ESLint territory. A formatter only reshapes whitespace and punctuation, it does not reject code for logic issues.
  • It does not fix syntax errors. If the input is invalid JS, the formatter will throw. Use it as a sanity check that your code at least parses.
  • It does not enforce naming conventions. camelCase vs snake_case is a lint rule, not a formatter one.

Common mistakes

  • Fighting the formatter. If you keep reformatting after it ran, you are both wasting time. Either configure the options, or accept the project’s choice.
  • Running format on a generated file. Bundler output, transpiled code, .min.js, none of them benefit. Format sources, not artefacts.
  • Formatting without parsing. A regex “pretty-print” will corrupt template literals, regex literals and JSX. Always use an AST-based formatter (like this one).

Frequently Asked Questions

Yes. The parser detects TypeScript syntax (types, interfaces, generics, decorators) and formats accordingly. JSX is also supported within .tsx / .jsx files.

It follows the same rules as Prettier’s defaults, configurable through the usual options (print width, quotes, semicolons, trailing commas). A file formatted here should match one formatted by Prettier with the same config.

The formatter requires valid, parseable JavaScript. If you get an error, the code likely has a syntax issue (unclosed brace, invalid JSX, typo). Run it through a linter first if the message is unclear.

Yes. Both single-line (//) and block (/* */) comments are retained in the output, positioned close to where they were in the source.

Related Tools

Tool available in other languages