Code Formatter

Format HTML, CSS, and JavaScript with Prettier.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Beautifies code by re-indenting pasted HTML, CSS or JavaScript with Prettier itself, running inside the browser rather than approximating its output.

How to use it

1Paste the code into the input box.
2Select HTML, CSS or JavaScript / JSON and press Format — the parser for that language is fetched on first use, so the initial run is slower than later ones.
3Copy the formatted result from the output box.

Example

Input: const a={x:1,y:2}
Output: const a = { x: 1, y: 2 };

Prettier's stock defaults apply — 80-column width, double quotes, semicolons inserted — and no .prettierrc is read, so the result may not match your project's house style. Also note the JavaScript / JSON option parses with Babel, so a bare JSON object such as {"a":1} is read as JavaScript and fails with Unexpected token; use the JSON Formatter for those.

What happens to your data

Prettier and the language parsers are downloaded to your browser and the formatting runs there, so your source is never uploaded or logged. That is the practical reason to use this rather than a server-side beautifier for anything proprietary.

Last updated August 2026

Somebody has handed you a file that arrives as one long line. It might be CSS lifted out of a browser's devtools, a script minified for production that you now have to read, or markup pasted into a ticket with every indent flattened out of it. You can work through it by counting brackets, or you can let a parser do the counting.

Before pasting anything, decide whether this is a one-off or the start of a habit. A one-off tidy — code you need to read once, that is not going back into a repository — is what a page like this is for. If the file belongs to a project, the formatter belongs in the project too: installed there, wired into your editor and a pre-commit hook, reading the same settings as everyone else on the team. Formatting a tracked file in a browser tab and pasting it back gives you a diff on every line and a house style that quietly disagrees with itself.

The other thing worth knowing is what formatting is not. It moves whitespace and rewrites a little punctuation; it does not check, fix or improve anything. A formatter also has to parse the code before it can print it, so broken code does not come back tidied — it comes back as an error naming the position where the parse gave up. That message is a useful way to find a stray bracket, but it is a side effect rather than the purpose.

Nothing is detected for you either. You pick the language from the dropdown, and picking wrongly produces a parse error rather than a guess.

How it works

Toolvore runs Prettier itself inside the tab rather than approximating its output with rules of its own. Pressing Format fetches Prettier's standalone build and then the parser plugins the chosen language needs — one for CSS, two for JavaScript, and four for HTML, since markup can carry both style and script and each of those needs its own parser. That fetch happens on first use, which is why the opening run is slower than the ones after it. Your code is then passed to Prettier's format function as an argument inside the page, along with the parser name and those plugins and nothing else — the honest limit here, because everything you would normally keep in a config file has no route in. Prettier reprints from the parse tree rather than editing your text, so most of the line breaks you chose are not carried over. And if the parser fetch fails, the message asks for a reload rather than another press: the module loader caches that failure per chunk, so a second attempt replays it without reaching the network.

Common use cases

Reading a minified script pulled from a live page
Tidying CSS copied out of browser devtools
Making a wall of pasted markup readable in a ticket
Locating a stray bracket by where the parse stops
Cleaning up a snippet before it goes into documentation
Sorting out mixed tabs and spaces in inherited code

Frequently asked questions

Why do I get an Unexpected token error instead of formatted code?＋

Because the code has to parse before it can be printed, and the message you see is the parser's own, passed through unchanged. Four causes cover most cases: a snippet cut mid-expression, so the brackets never close; a fragment of a template language, where the surrounding braces and percent signs are not valid in the language it was pasted as; a diff pasted with its leading plus and minus markers still attached; and the wrong entry chosen in the dropdown, which makes a perfectly good stylesheet fail as JavaScript. The position quoted is where the parser gave up, which is usually somewhere after the real mistake.

Can I get four-space indents, tabs or single quotes?＋

Not from this page. The formatter is called with the language's parser and nothing else, so there is no settings panel and no way to hand it an indent width, a quote preference or a line length. If those choices matter — because the output is going into a codebase that has already made them — run Prettier where the project's own configuration can be read, through your editor's Prettier extension or with npx prettier --write on the file. Treat this as a way of reading code rather than a way of producing code you intend to keep.

Is my code uploaded anywhere when I format it?＋

No. The formatter is downloaded to your browser and your code is handed to it as a function argument inside the page. There is no upload step in the component, no request that carries the contents of the input box, and no server that could keep a copy. The network activity a format does produce runs the other way: Prettier's code and its parsers arriving on your machine. That is the difference that matters when what you are pasting is a config with a hostname in it, a snippet from a private repository, or anything else you would not put into someone else's server-side beautifier.

Why is the first format slow, and why does an error tell me to reload?＋

The formatter and its parsers are not part of the initial page — they are fetched the first time you press Format, so the opening run pays for that download and later ones do not. Switching language can trigger another fetch, because each one loads a different set. When that download fails, on a flaky connection or through a blocking proxy, the message asks you to reload the page rather than press the button again. That is not boilerplate advice: the module loader caches the failed request, so pressing Format a second time replays the same failure without trying the network.

Can it handle TypeScript, JSX, Python or PHP?＋

The dropdown offers HTML, CSS and JavaScript, and the parsers behind them are the HTML, PostCSS and Babel ones — so TypeScript is not covered. Type annotations, interfaces and enums fail to parse, because the parser that understands them is not among those downloaded. JSX is Babel territory and generally goes through. Python, PHP, Java and SQL are not Prettier core languages at all; Prettier reaches them only through community plugins, and none are loaded here. For anything outside the three on offer, format it in your editor rather than hunting for a setting that does not exist.

Why did the CSS and JavaScript inside my HTML get reformatted too?＋

Because formatting markup means formatting what is embedded in it. Choosing HTML loads four parsers rather than one: the HTML parser for the markup, PostCSS for anything inside a style element, and the Babel pair for anything inside a script. An inline stylesheet or a block of script is therefore re-indented by the same rules that would apply if you had formatted it on its own. That is usually what you want, and it is worth knowing before you paste a server-side template whose script block holds templating syntax that is not valid JavaScript.

Should I commit a reformatted file to git?＋

Reformatting a tracked file rewrites nearly every line, which buries the change you actually made and pushes the old authorship out of git blame. The usual discipline keeps the two apart: one commit that only reformats, another that changes behaviour, never both at once. If a repository is being formatted for the first time, do the whole thing in a single sweep and record that commit's hash in a .git-blame-ignore-revs file, which git blame --ignore-revs-file will skip. Agree the settings in the repository first, so the next person's editor does not quietly reformat everything back.

What is the difference between a formatter, a beautifier, a minifier and a linter?＋

A formatter and a beautifier are the same idea under two names: reprint the code so a person can read it, without changing what it does. A minifier goes the other way — strip whitespace, shorten names, produce something small to send over a network and unpleasant to read. A linter is a different job again: it looks for suspect code, unused variables and likely bugs, reporting on meaning rather than layout. They stack rather than compete. Format for humans while you work, minify on the way to production, and leave a linter to catch what neither of the others is looking at.