SQL is famous for being written once in a hurry and read many times under pressure. A consistent format is one of the cheapest ways to make queries reviewable, debuggable, and shareable. This guide covers why formatting matters, the conventions behind keyword casing, and when to reach for minify.
Readable queries make better code reviews
A query crammed onto one line hides its own structure. When every clause — SELECT, FROM, each JOIN, WHERE, GROUP BY — starts on its own line, a reviewer can see at a glance which tables are joined, on what keys, and which filters apply. Indenting the select list and the join conditions adds a second layer of structure: you can scan the columns without parsing the whole statement. The result is fewer missed bugs (a forgotten join condition is obvious when ON sits on its own indented line) and faster reviews. Because this formatter only rearranges whitespace and casing, the meaning of your query never changes — it is purely cosmetic, which is exactly what you want in a diff.
Keyword casing conventions
The long-standing convention is to write SQL keywords in UPPER CASE and identifiers (tables, columns, aliases) in lower or mixed case. The contrast makes the language scaffolding pop out from your schema. Some teams prefer all-lowercase SQL for a softer look, and a few use Capitalized keywords. There is no single correct choice — what matters is consistency across a codebase, which is why a formatter that applies one rule everywhere is so useful. This tool re-cases only recognised keywords; your table and column names keep whatever casing they already have, and anything inside a string literal or comment is never altered.
When to minify
Minifying — collapsing a query to a single line — is the opposite of beautifying, and it has its place. When a query has to live inside application source code as a string constant, inside a JSON or YAML config value, or in a shell one-liner, line breaks get in the way. Minify removes them while keeping every string literal's contents intact, so the query still runs identically. One caveat the tool handles for you: single-line (--) comments cannot survive on a one-line query because they would comment out everything after them, so minify drops comments. If you need the readable version back, just paste the minified query into the Beautify tab.
A formatter is not a validator
It is worth being clear about the boundaries. This tool formats text — it does not connect to a database, run your query, or check that it is valid SQL. If you paste something it cannot fully parse, it still applies best-effort spacing and flags the output as a partial format rather than failing. That makes it safe and fast for everyday use, but you should still run your query against a real database (or a linter) to confirm correctness. Think of formatting as the first, cheapest step in writing clean SQL, not the last word on whether it works.