JavaScript formatter and beautifier

The formatter re-flows JavaScript so you can read it:

• starts a new line after {, } and ;,
• indents each block one level deeper than its parent,
• keeps for (let i = 0; i < n; i++) on one line, because those semicolons belong to the loop header,
• leaves strings, template literals and regular expressions untouched, so their content can never be changed by formatting.

For example, function total(a,b){if(a>b){return a-b;}else{return a+b}} becomes a properly indented function with the if and else blocks on separate lines.

The code is not executed and not sent anywhere. It is processed as text in your browser, so it is safe to format proprietary or internal code.

• Reading minified code from a website, a browser extension or a third-party library to understand what it does.
• Debugging a production bundle when no source map is available.
• Cleaning up snippets copied from chat, email or Stack Overflow that lost their indentation.
• Tidying TypeScript, JSX or JSON: the same brace-and-semicolon rules apply, so these files work too.
• Quick fixes on a machine without your usual editor setup.

For JSON specifically, the JSON formatter also validates the syntax and pinpoints errors.

This is a fast, lightweight re-indenter, not a full parser. That means:

• It does not check whether the code is valid. A missing brace leads to odd indentation rather than an error message.
• It does not rename variables. Minified code keeps its short names like a, b and e, which cannot be recovered without a source map.
• It does not reorder or rewrite code, add missing semicolons or apply a style guide's spacing rules around operators.
• Very unusual syntax, such as code relying on automatic semicolon insertion across lines, may be broken into lines differently than you would expect, but the code itself is not altered.

For project-wide, rule-based formatting, use Prettier in your editor or build. For a quick look at a snippet, this tool is faster.

Style	Common in
2 spaces	Most JavaScript and TypeScript projects, Prettier's default, Google and Airbnb style guides
4 spaces	Projects shared with Python or Java teams, some Node.js codebases
Tabs	The Go and Linux kernel traditions; lets each developer set the width they prefer

There is no technically correct answer. What matters is that a project uses one style consistently, ideally enforced by an .editorconfig file or a formatter, so diffs do not fill up with whitespace changes.

Minified code has had whitespace and comments removed and local names shortened, purely to make files smaller. Formatting restores the layout, and the logic becomes reasonably readable.

Obfuscated code has been transformed on purpose to be hard to understand: strings hidden in encoded arrays, control flow flattened into switch statements, dead code inserted. Formatting helps a little, but the logic stays hard to follow.

If you are inspecting a script because you are unsure whether it is safe, for example code a website or extension injects, formatting it is a good first step. Look for network calls, eval, and long encoded strings.