Which Code Formatter Do You Need? JS, CSS, SQL, Python

#What formatting changes, and what it does not

Formatting adjusts whitespace only - indentation, line breaks, spaces - and leaves semantics untouched. That guarantee is what makes formatters safe: the result behaves exactly like the input, only more readable.

Two opposite directions are worth keeping straight:

#JavaScript: line breaks carry meaning

JavaScript's automatic semicolon insertion (ASI) gives line breaks semantic weight, a risk unique to JS. These two functions do completely different things:

class="tk-c">// This one returns undefined
function f() {
  return
  { value: 1 }
}

class="tk-c">// This one returns the object { value: 1 }
function f() {
  return {
    value: 1
  }
}

In the first version the newline after return triggers an inserted semicolon, and the object becomes a discarded statement. This is most dangerous during minification, where removing newlines can join return to the expression that follows and change behaviour.

The safe practice: before minifying, confirm there are no bare line breaks after return, break, continue or throw, and avoid starting a line with (, [, + or - when it continues a previous expression.

#Python: indentation is syntax

Python uses indentation to define blocks, so a formatter must preserve the original hierarchy. This is fundamentally different from C-style languages, where braces determine structure and indentation is cosmetic. In Python, wrong indentation means either an IndentationError or silently different logic.

When you run Python Formatter, it normalizes inconsistent indentation to 4 spaces - it does not re-infer the hierarchy. If the pasted code had incorrect indentation to begin with, the output preserves that error, and a human needs to confirm the structure.

#CSS: aligning nested media queries

The main value of CSS formatting is aligning nested media queries and selector levels. Minified CSS typically looks like this:

.a{color:red;padding:8px}@media(max-width:640px){.a{padding:4px}}

Formatted, the hierarchy becomes visible, and you can see at a glance which rules apply only at a given screen width:

.a {
  color: red;
  padding: 8px;
}

@media (max-width: 640px) {
  .a {
    padding: 4px;
  }
}

#SQL: the dialect decides the quotes

SQL keyword case never affects execution, but identifier quoting is dialect-specific, which is where SQL formatting goes wrong most often:

A formatter that normalizes all quoting to one style produces statements that fail on another database. So pick the target dialect in SQL Formatter first, then verify the quotes survived intact.

Note also that string literals are never reformatted, including any part that looks like a keyword or a comment. That is correct behaviour, not a bug.

#Which tool for which job

#Frequently asked questions

#Can formatting break working code?

Ordinary beautification cannot, because it only touches whitespace. Two exceptions exist. First, indentation-sensitive languages like Python: if the input indentation was already wrong, the formatter preserves the error. Second, minification: deleting line breaks can change semantics at JS return statements. Beautifying is generally safe; minifying deserves care.

#How much smaller does minification make a file?

It depends on the original indentation and blank-line density. A typical range is 20-50% smaller, with indentation spaces accounting for most of it - code that uses 4-space indentation and generous blank lines benefits most. Comments are usually stripped too, so if a licence header must survive, verify the tool's behaviour first.

#Should I review the output by hand?

A quick scan is worthwhile, focusing on three constructs: string literals, regular expressions and template literals. These can contain characters that resemble code syntax, which is where mistakes happen. Also verify SQL quoting and the Python indentation level.

#Why did formatting fail with an error?

A formatter must parse the code first, and parsing fails when the code is not valid. That usually means a real syntax error: unbalanced brackets, an unterminated string, a missing comma. The reported position typically points at or near the problem - fix it manually and retry.

#Does formatting keep comments?

Beautifying keeps them. Minifying usually removes them, since comments do not execute and consume bytes. If a licence header must remain for legal reasons, add it back after minifying, or use a build tool that preserves designated comments.

#Is an online tool enough to standardise a team's style?

No. Online tools are for one-off fragments. For a team, use an editor plugin or a formatter in the build pipeline (Prettier, Black, gofmt) so it runs on save - that way consistency is enforced by tooling rather than by personal habit. Online formatters are best for the "quickly understand unfamiliar code" case.