Why Formatting SQL Matters (and What a Formatter Does)

Published July 19, 2026

An ORM logs a query and it lands in your console as one 300-character line. A formatter turns that wall of text into an indented, scannable query where every clause has its place. It’s the same query — just legible. Here’s what’s actually going on.

One long line in, readable query out. We gave our SQL formatter this, all on one line: select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=1 group by u.id,u.name having count(o.id)>2 order by orders desc. It came back with each clause on its own line, the selected columns indented beneath select, and — the part that matters — spaces inserted around = and > so o.user_id=u.id became o.user_id = u.id. Notice it did not uppercase the keywords: that is a separate option, because changing case is a stylistic choice while indentation is not.

What formatting changes (and what it doesn’t)

Formatting only touches whitespace, line breaks and indentation — plus, optionally, the case of keywords. It puts SELECT, FROM, WHERE, JOIN and GROUP BY on their own lines, indents the columns and conditions, and lines up the structure so nesting is obvious.

What it never changes: your tables, columns, values or logic. A formatted query returns exactly the same result as the cramped one. That also means formatting is not validation — it won’t tell you a column is misspelled or that the query will actually run.

Dialects: why the tool asks which database

SQL has a standard, but every database adds its own flavour, and the formatter needs to know which one to parse correctly:

Identifier quoting — MySQL uses backticks (`col`); PostgreSQL and standard SQL use double quotes ("col").
Row limiting — LIMIT in MySQL/SQLite/PostgreSQL, TOP in SQL Server.
Casts — PostgreSQL’s value::int has no equivalent elsewhere.

Pick the wrong dialect and these get mis-parsed, so the indentation comes out wrong. Choose your actual database in the SQL formatter before you paste.

Uppercase keywords: style, not rule

Many teams write keywords in UPPERCASE (SELECT, FROM) so they stand out from table and column names. SQL itself is case-insensitive for keywords, so this is purely a readability convention — a formatter can apply it consistently across a whole query in one click.

Case is the one thing our SQL formatter deliberately leaves alone. A lower-case query, formatted:

select
  *
from
  users
where
  id = 1

and the same shape typed in upper case:

SELECT
  id,
  name
FROM
  t
WHERE
  a = 1
  AND b = 2

Lower-case select stays lower-case; upper-case SELECT stays upper-case. The default is preserve, because re-casing keywords is a house style rather than a correctness fix — and changing it silently would make the diff of a formatting-only commit unreviewable, which is the one thing a formatter must never do.

Why do it locally?

A client-side formatter parses and re-prints the SQL in your browser. Your queries — which often reveal schema and business logic — never leave your machine.

Cleaning JSON instead? Use the JSON formatter.
Moving query results between formats? Try JSON ⇄ CSV ⇄ Excel.

Before and after

The same query, minified by an ORM and then formatted:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=1 group by u.id,u.name having count(o.id)>0 order by orders desc;

Formatted, the structure reads top to bottom:

SELECT
    u.id,
    u.name,
    COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = 1
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 0
ORDER BY orders DESC;

Same result, but now the joins, filters and grouping are obvious at a glance.

What formatting does change is where the line breaks fall. An INSERT collapsed onto one line comes back as:

insert into
  logs (a, b)
values
  (1, 2)

The clause keyword takes its own line, its operand is indented beneath it, and the column list keeps its commas inline. That is the entire algorithm — one clause per line, operands indented — and once you can predict it, a formatted file becomes reviewable by shape alone: a WHERE that is not at the left margin is a WHERE inside a subquery.

Leading vs trailing commas

Two common column styles: trailing commas (u.id, at the end of each line) or leading commas (, u.name at the start). Leading commas make version-control diffs cleaner — adding a column touches one line instead of two — but both are valid and most formatters let you pick. Consistency within a codebase matters more than which side you choose.

Common questions

Does formatting affect performance? No. The parser ignores insignificant whitespace and keyword case, so a formatted query is equivalent to the engine. Only the contents of string literals are ever whitespace-sensitive.
Should I commit formatted SQL? For views, migrations and stored procedures, yes — a consistent style keeps diffs small and reviews fast.
Formatting won’t fix a broken query, though. It only rearranges text; use a real database or linter to catch errors. Exporting the results afterwards? See how to convert JSON to CSV and Excel.

#sql#dev