Code Formatters
SQL / HTML / CSS / JS / XML · 6 tools
A formatter does one thing: it re-emits your source with consistent whitespace. It does not fix bugs, rename anything, or validate semantics. For SQL, CSS, JS, JSON and most XML that is safe, because whitespace between tokens carries no meaning.
Two formats in this category are not safe by default. HTML collapses runs of whitespace when rendering, so a newline inserted between two inline elements becomes a visible space, and content inside pre, textarea, script and style cannot be reflowed at all. XML has no such rule: whitespace between elements is part of the document, and a signed XML document cannot be formatted at all without invalidating the signature.
Which one do I need?
- One-off readability: paste, format, copy back. Fine for anything that is not whitespace-sensitive.
- CSS with calc(): the spaces around + and - are required by the grammar. The formatter preserves them; do not remove them manually when tidying up.
- HTML fragments: check the rendered result afterwards. Inline elements separated by a newline gain a space, which shows up as an unexpected gap.
- XML that carries a signature: do not format it. Any change to element whitespace changes the canonical form and the signature check will fail.
- nginx configuration: the brace matcher can misread a regex quantifier such as {2} as a block opener. Formatting is cosmetic — validate with nginx -t before deploying.
- Shrinking JavaScript: this is whitespace-level minification, not an AST-level compiler. It will not rename variables, drop dead code or mangle scopes; use a real bundler for production builds.
All tools in this category
Guides in this category
- SQL formatter: style conventions, execution order, and what reformatting can silently get wrongFormat SQL with keyword casing and clause indentation
- HTML beautifier: void elements, whitespace sensitivity, and spaces between inline elementsIndent HTML by tag nesting; keep script and style contents untouched
- CSS formatter and minifier: why the spaces inside calc() must not be removedBeautify CSS with indentation, or minify to strip redundant whitespace in one click
- JS beautifier and the "minify" limit: why it should not replace a real minifierIndent JS by braces for beautifying; protect strings when minifying
- XML formatter: validity requirements and the exception where formatting changes meaningIndent XML by tag nesting, or compress into a compact single line
- Nginx config formatter: the brace trap and why formatting is not validationLine-break and indent by { } and ; to tidy up conf hierarchy
FAQ
Can formatting change what my code does?
For JS, CSS, SQL and JSON, no — whitespace between tokens is insignificant and the token stream is unchanged. For HTML it can change rendering (collapsed whitespace becomes visible between inline elements), and for XML it changes the document itself, because text nodes including whitespace are content. The tool reports what it changed, but the rendered result is the real check.
Does a successful format mean the code is valid?
No. The formatter tracks brackets and quotes; it does not compile. JavaScript can format cleanly and still throw at runtime, CSS can format cleanly with an unsupported property, and nginx can format cleanly with a directive that nginx itself rejects. Formatting is cosmetic, validation is separate.
Why is my minified JS still large?
Because whitespace is only part of the story. Comments and indentation get removed here, but identifier names, unused functions and unused branches are untouched — they are typically a much larger share of the file. That is the difference between a formatter and a compiler-based minifier.