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. The formatter is intended to change only whitespace and recognised keyword casing, but it is best-effort text processing rather than a SQL parser, so review the output and validate important queries with your database tooling.
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 formatting whitespace while keeping string-literal contents intact. It also drops comments, because a single-line (--) comment would comment out everything after it; review the result and validate important queries with your database tooling rather than assuming every input is semantically unchanged. 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.