About JS Formatter
The JavaScript formatter re-indents code by tracking braces and semicolons, placing each block on its own lines with two-space indentation. It is aware of string literals — including template literals — and of comments, so punctuation inside them is not mistaken for structure.
It is worth being clear about what it is: a lightweight indenter rather than a full language-aware formatter. It does not parse regular expression literals, does not re-wrap long lines, and does not rearrange anything. For a minified file that has been collapsed onto one line, that is usually enough to make the code readable again.
Where it genuinely helps is with generated or shipped code — a bundled dependency, a build output, a snippet copied out of a production page — where you need to understand the structure rather than adopt it as your own source. For code you actually maintain, a formatter integrated into your editor will handle the full grammar more accurately.
How to use JS Formatter
- 1 Paste the JavaScript source.
- 2 Blocks are indented by two spaces with statements placed on their own lines.
- 3 Copy the output to read or review the structure of the code.
Frequently asked questions
Will this reformat my code the way Prettier would?
No. It applies consistent indentation based on braces and semicolons rather than parsing the full language grammar. It makes collapsed code readable, but it does not wrap long lines, align arguments, or normalise quoting style.
Are strings and comments handled correctly?
Yes — string literals including template literals, and both line and block comments, are tracked so that punctuation inside them is not treated as code structure. That is what prevents a semicolon inside a string from being read as a statement boundary.
Does it handle regular expression literals?
No. A regular expression containing a brace or a semicolon can confuse the indentation, because distinguishing a regex literal from a division operator requires parsing the language. Check the output if your code contains complex regular expressions.
Is the output safe to run?
The tokens are unchanged and only whitespace between them is adjusted, so the code runs as before — with the caveat that automatic semicolon insertion means whitespace placement can matter in a few edge cases. Verify before running formatted code in production.
Free, online, and private
Free to use
JS Formatter is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How JS Formatter behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Indent unit | 2 spaces, one level per unmatched `{` |
| Line-break triggers | a `{`, a `}`, a `;` and the end of a `//` comment — nothing else causes a break |
| String handling | single, double and backtick quotes are tracked, with backslash escapes, so braces and slash characters inside them are not read as code |
| Comment handling | recognised and preserved — `//` runs to the end of the line and `/* … */` to its closing marker; both are copied into the output rather than stripped |
| Commas | never produce a line break, so object and array members stay on one line |
| Cleanup pass | spaces before , ) ] are removed and three or more newlines collapse to two |
Compiled from the implementation of this tool and checked against it by itoolnet.
What JS Formatter does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- Line breaks are dropped unless a `{`, a `}`, a `;` or a line comment produced them, so code that leans on automatic semicolon insertion is welded together: two statements on separate lines with no semicolons end up as one line that will not parse.
- Indentation is a flat counter of unbalanced braces with no syntax analysis, so a brace inside a regular-expression literal counts as a real block. The pattern /a{2}/ is rewritten with the quantifier on its own line, and the result no longer compiles as a regular expression.
- A "/*" sequence inside a regular-expression literal opens a block comment that never closes, and the scanner stays in comment mode for the rest of the file — nothing after that point is indented or broken onto a new line, and the formatting stops without reporting anything.
- Only a `;`, a brace or a line comment ends a line. A long object literal or argument list is never broken at commas, while an opening brace always forces a break, so a one-line object literal becomes a brace on its own line with all its members jammed below it.
- Closing braces leave a blank, whitespace-only line behind: the `}` handler emits a newline plus the indent, and the `;` handler has already ended the previous line, so every block ends with an empty line carrying trailing spaces.
Tested and documented by itoolnet, the team that builds and maintains this site.