The tool is deliberately a re indenter and not a full pretty printer. It does not reorder your code, break long expressions across lines by width, or add and remove semicolons. It restores the structure that braces and statement terminators already describe, which is almost always what you need when you are trying to read something rather than rewrite it.
All of the work happens in your tab. A proprietary bundle, an unreleased feature flag or a snippet from a private repository is never transmitted anywhere, so you can beautify javascript code from work without thinking about a data policy.
When a JavaScript formatter earns its keep
The obvious case is production debugging. A stack trace points at line 1 column 48213 of a minified bundle, and no amount of squinting will tell you which function that is. Reindenting the file gives every statement its own line number, so the column offset becomes a line you can navigate to.
The less obvious case is code that arrives through a channel that eats whitespace. Chat clients, issue trackers, spreadsheets and email all strip or mangle leading spaces. Code pasted through them is syntactically valid and completely unreadable, and running it through a js beautifier is faster than reindenting it by hand.
- A stack trace refers to a column offset inside a minified bundle.
- Someone pasted a function into chat and every level of indentation vanished.
- You are reviewing a vendor script before allowing it onto a page.
- A generated file needs to be read once and will never be edited.
- Mixed tabs and spaces make the nesting depth ambiguous.
How this JavaScript formatter reads your code
The scanner walks the source one character at a time and keeps track of the context it is in. Inside a single quoted string, a double quoted string, a template literal, a line comment or a block comment, characters are copied through untouched and no brace is treated as structural.
Outside those contexts it maintains two counters. Curly braces raise and lower the indent level and force a line break. Round and square brackets are counted but do not force a break, which is what keeps the three clauses of a for loop header on one line where they belong.
Template literals get special handling because they can contain interpolations that themselves contain braces and even nested template literals. The scanner tracks interpolation depth so that a brace inside a placeholder is never mistaken for the end of a block.
What this JavaScript formatter cannot see
There is no parser here, so there is no syntax tree, and a few things are genuinely ambiguous without one. The clearest example is the forward slash, which starts a regular expression in one context and means division in another. The scanner resolves this by looking at the last meaningful character before the slash, which is the same heuristic editors use and is correct for essentially all real code.
Automatic semicolon insertion is the other limit. Code written without semicolons has statement boundaries that only a parser can find, so a semicolon free file will be indented correctly by braces but will not gain one statement per line. Nothing is broken, the output is simply less finely divided than it would be for a semicolon terminated file.
Indent width and the options worth changing
Two spaces is the default and matches the convention of most modern JavaScript projects and the style guides they follow. Four spaces suits code with shallow nesting or a team coming from other languages. Tabs let each reader choose their own visual width, which is the accessibility argument for them.
The blank line option controls whether the formatter preserves the empty lines you wrote. Keeping them is normally right for source you will keep editing, since the author used them to group related statements. Dropping them makes the most compact readable output, which is what you usually want when you format javascript online purely to read a bundle once.
Everything else is fixed on purpose. Opening braces stay on the same line as the statement that introduces them, because that is what almost every JavaScript style guide specifies and inconsistency here is more distracting than any particular choice.
Reading a minified bundle safely
A formatted bundle is still someone else's code, and reading it is the point at which people sometimes execute it to see what it does. Do not. Reindent it, read it, and search for the strings and network calls that tell you what it touches. This JavaScript formatter never evaluates the input, it only reprints it.
For very large bundles, search the formatted output rather than the original. A search for a domain name in an indented file gives you a line you can read in context, while the same search in a single line file gives a match in the middle of nothing.
Bundles over a few megabytes will make any browser text area sluggish. When you need to indent javascript at that scale, split the file first or download the result rather than scrolling it in the page.
| Aspect | Behaviour |
|---|---|
| Indentation | Rebuilt from curly brace depth |
| Line breaks | Added after braces and statement terminators |
| Semicolons | Never added or removed |
| Identifiers | Never renamed or expanded |
| Comments | Preserved in place |
| Strings and templates | Copied byte for byte |
How to use the JavaScript formatter
- 1
Add your script
Paste JavaScript into the input box or drop a .js file onto the drop area. The file is read on your own device.
- 2
Choose an indent
Pick two spaces, four spaces or a tab. Two spaces is the default and matches most modern JavaScript projects.
- 3
Decide about blank lines
Keep the author's blank lines when you plan to edit the code, or drop them for the most compact readable output.
- 4
Format and take the result
Press format, then copy the output or download it as a .js file you can open in your editor.
Related tools worth bookmarking
Sources and further reading
- MDN: JavaScript lexical grammarHow the language tokenises comments, string literals, template literals and automatic semicolon insertion.developer.mozilla.org
- TC39: ECMAScript language specificationThe normative specification, including the rules that make regular expression and division syntax ambiguous.tc39.es
Frequently asked questions
Common questions about the javascript formatter.
No. Only whitespace between tokens is added or removed, and whitespace outside strings and template literals has no meaning in JavaScript. Statements, expressions, comments and identifiers all survive exactly as you wrote them.
No, and neither can any other tool. Minifiers rename identifiers to single letters and discard the originals, so the information is simply gone. What you get back is readable structure with short names, which is usually enough to follow the logic.
Yes. Template literals are copied through with their interpolations intact, including nested braces and nested templates. Regular expression literals are detected by looking at the preceding token, the same heuristic that code editors use for syntax highlighting.
Partly. Braces, brackets and strings behave the same way, so indentation is generally correct. JSX in particular will be indented by its braces rather than by its element nesting, which is readable but not what a dedicated JSX formatter would produce.
No. Everything runs as JavaScript inside your browser tab, so nothing leaves your machine. You can confirm it by opening the network panel of your developer tools and formatting a file while watching for requests.