JavaScript formatter

This JavaScript formatter moves whitespace and nothing else

Most tools that call themselves a JavaScript beautifier read your file into a syntax tree and then print that tree back out. What you get is the printer’s idea of your code: its quote style, its number spelling, its spacing inside brackets. Single quotes become double quotes. 0xff becomes 255. Comments that sat in the middle of an expression have nowhere to hang and quietly disappear.

This one works on the characters instead. It walks the text you handed over and changes only the spaces, tabs and line breaks between the pieces. Your quotes stay the quotes you typed, your numbers stay spelled the way you spelled them, and your comments come back word for word. We counted: across 13,120 real dependency files taken from this project, not one file lost a single word out of a comment, and the stream of non-whitespace characters going out was identical to the stream going in, every time.

That is a narrower promise than “beautify”, and it is a deliberate one. The opposite direction lives on its own page: the JavaScript minifier takes representation bytes away and is honest that names and comments cannot be reconstructed once they are gone. These two are not a switch on one page, because taking whitespace out and putting it back are different jobs with different risks.

What still looks different after the beautifier has run

Getting your own characters back is not the same as getting the file you expected. We measured what changed across those 13,120 files, and the receipt on this page tells you which of these happened to your file rather than leaving you to find out.

Blank lines get added — that was true of 40.4% of files. A blank line goes in front of a function declaration that did not have one, even in a fully minified file. A final line break is added to 20.5% of files that ended without one. Runs of three or more blank lines are shortened to two, and spaces left at the ends of lines are removed.

The surprise most people do not expect is that lines can get longer. It happened to 8.0% of files. Nothing here breaks a line to fit a width, so a long line stays long — and a ternary that you split neatly over three lines is joined back into one. A conditional with the ? and : at the starts of lines comes back with them at the ends. This is the tool doing what it was asked, but it looks like the opposite of formatting, so the receipt says so out loud.

Braces go the other way: short ones are opened up. import{api}from'./api.js' comes back as three lines, with api alone on the middle one, and a destructured parameter such as ({ name, price }) gets a line per name. The layout has no notion of “short enough to stay on one line”; the only switch that keeps an object on one line also keeps whole function bodies on one line, which would leave a minified file as unreadable as it arrived.

Line endings survive: of 33 files that used Windows line endings, 32 kept them. The one that did not had a mixture of both, and a mixed file is normalized to Unix endings throughout. Tabs become spaces only because two spaces is the default — pick Tab above and a tab-indented file stays tab-indented.

Why a whitespace-only tool still needs a second opinion

In JavaScript a line break can be syntax. Automatic semicolon insertion means the end of a line sometimes ends a statement, and moving that line break changes the program. This is not a theoretical worry. The argparse package writes let subnamespace on one line and destructures into it on the next; joining those two lines produces something that is not valid JavaScript at all. Six of our 13,120 files broke exactly that way.

Backtick strings are the other trap. Inside a template literal, spaces and line breaks are not layout — they are the text. Adding an indent inside one changes the value it produces, and putting a space between $ and { turns an interpolation into ordinary characters. Twenty-two files hit that, mostly deep inside CSS tooling.

So every run is read twice, by a reader that has nothing to do with the part that moved the whitespace, and the two readings are compared. Comments are counted on both sides. If anything disagrees, you get nothing back rather than a file that looks tidy and behaves differently. That is the same standard the JSON formatter and the HTML formatter hold themselves to, and it is why they all run inside your browser — you can check that yourself on the guide to verifying local processing.

Five refusals, and not one of them says “something went wrong”

An empty box is never submitted at all — the button stays off until there is something to format, so you get the answer before you press rather than after. Text that is not JavaScript gets a line and a column you can go to, and a note that TypeScript and JSX need a different tool. A layout that breaks the file takes the blame itself, because your file was fine going in. A layout that would change what your code does explains where to look. And two more — a lost comment, and a layout that will not settle after eight rounds — have never once fired in the files we measured, so if you see either of them the message says so instead of implying you did something wrong.

Module, script, and what this formatter will not touch

You are not asked whether the file is a module or a classic script, because you would have to guess and the file already answers. The stricter module rules are tried first, and they fit nearly everything: of our 13,120 files, 13,116 read as modules and four needed the older and looser script rules — with, for instance, is allowed only there. The receipt reports which rules fitted, as a fact rather than a switch you might set wrongly.

TypeScript, JSX and minified bundles with source maps are outside what this accepts, and they fail with a position rather than being half-understood. If what you have is a data object rather than a program, the JavaScript object to JSON converter has the narrower parser for it, and if the material is a query instead the SQL query formatter handles that grammar. Copy and download always use the complete result, even when the panel shortens what it shows for a very large file.