Code Beautifier & Minifier
Beautify or minify HTML, CSS and JavaScript in one tool, with structural re-indenting and an honest account of what an automatic formatter can and cannot fix.
Structural re-indenting and conservative minification — comments and dead whitespace go, but JavaScript tokens are never merged across lines, so semicolon-insertion behavior is preserved. For opinionated production formatting, Prettier remains the standard; for shipping-grade JS compression, a real minifier (terser) renames and tree-shakes.
A greater-than sign inside an attribute splits the tag
This formatter finds tags by splitting on angle brackets rather than parsing, which the page says plainly. Here is exactly what that costs:
| Input | Lines out | Attribute survives |
|---|---|---|
| <p title="a > b">x</p> | 4 | no |
| <p title="a < b">x</p> | 4 | no |
| <p title="a to b">x</p> | 3 | yes |
The clean version formats to 3 lines; the one with a bracket in the attribute comes to 4, with the attribute torn across a line break and the nesting wrong from there on. A less-than sign does the same in the other direction, opening a tag that never closes and leaving everything after it over-indented (4 lines). Both inputs are perfectly legal HTML — the character that must be escaped inside an attribute value is the quote, not the bracket. Writing it as > avoids the problem entirely and is worth doing anyway.
A brace inside a CSS string used to close the block
The CSS side used to walk the text counting braces and semicolons without tracking whether it was inside a string, so quoted punctuation was taken at face value and a declaration like content: "}" came apart. It now skips a quoted value the way it skips a comment:
| Input | Lines out |
|---|---|
| a { color: red; } | 3 |
| a { content: "}"; color: red; } | 4 |
| a { content: "a;b"; color: red; } | 4 |
The plain rule comes out in 3 lines and the one with a quoted brace in 4 — one line per declaration, the same as any other rule. A quoted semicolon is content too, and no longer splits one declaration into two. Both are valid CSS, rare by hand and entirely normal in generated CSS, where content strings carry punctuation routinely. Comments and nesting are handled explicitly and come through correctly as well. The angle-bracket problem above is still real; this one is not.
The part that is cleverer than it looks
Before formatting, the contents of pre, script and style are lifted out and replaced by a numbered placeholder so their whitespace survives untouched. Restoring them means finding those markers again — and the obvious way to write one, a number surrounded by spaces, would collide with any ordinary text containing a number.
It does not use spaces. The delimiter is a NUL byte, which cannot appear in HTML source, so "chapter 7 begins" is never mistaken for placeholder 7. Every number from 0 to 120 was checked in ordinary text and all of them come through unchanged. Even with a real stashed block present, so that placeholder 0 genuinely exists, a literal "0" in the surrounding text is left alone. Which is the whole reason the stashing is there: whitespace inside a pre block is meaningful and must not be reformatted. That is an easy thing to get wrong, and there is nothing on the page to tell you it was got right.
The minifier makes a similar distinction: ordinary comments are dropped and conditional ones are kept, since those are instructions rather than notes. On the sample above it saves 49%.
How to use
- Paste your code and pick the language.
- Choose beautify or minify.
- Set your indent size and style.
- Copy the result.
Frequently asked questions
Does formatting change what my code does?
It should not, and for well-formed code it does not. The exceptions worth knowing are template literals and multi-line strings, where whitespace is content rather than formatting, and any language where indentation is significant. Reformatting Python by an HTML formatter would be destructive.
Why use a formatter rather than formatting by hand?
Because it removes an entire category of argument and review comment. When formatting is automatic and consistent, code review discusses behaviour rather than brace placement, and diffs show real changes rather than whitespace churn.
Tabs or spaces?
A genuinely unresolved argument with reasonable cases on both sides. Tabs let each reader choose their own indent width, which is a real accessibility benefit; spaces guarantee identical rendering everywhere. What matters far more than the choice is that a project makes one and enforces it.
What does minifying actually remove?
Whitespace and comments at minimum. More aggressive minifiers also shorten local variable names, remove unreachable code and rewrite expressions into equivalent shorter forms. The last of these can expose latent bugs in code that relied on undefined behaviour.
Should I minify by hand for production?
No — your build tool should do it as part of the pipeline, so the source stays readable and the minified output is generated fresh each time. Hand-minifying produces a file nobody can maintain and that drifts from the source it came from.
Can a beautifier fix broken code?
No, and it should not try. A formatter needs to parse the code to reindent it structurally, so genuinely broken syntax will either fail or produce nonsense. Fix the syntax error first; the formatter is not a repair tool.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.