Every developer eventually inherits the query: 400 lines, one line, lowercase keywords, six nested subqueries, written by a BI tool or a contractor or 2019-you. You can't review it, you can't debug it, and you definitely can't tell which of the four LEFT JOINs is the one duplicating rows. Pasting it into an online SQL formatter is the difference between reading the query and spelunking it. Thirty seconds, and structure you can actually reason about.
This is a short guide on what a formatter actually does for you, the style calls that matter (and the ones that are pure tribal warfare), and the thing formatting will never fix.
SQL is one of the few languages where most code is read by someone other than its author — analysts inherit engineers' queries, engineers inherit BI-tool exports, everyone inherits the data vendor's. Unformatted SQL hides logic: a WHERE clause that quietly turns your LEFT JOIN into an inner join, a UNION ALL buried mid-query, an aggregate filter living in the wrong place. Formatted, those jump out. There's a reason code review culture treats "I reformatted it first" as step zero of debugging someone else's query.
It also fixes diffs. One-line queries produce one-line diffs — the review equivalent of "trust me." Formatted SQL with one clause per line means your version control shows exactly which condition changed. If your team reviews SQL in pull requests, consistent formatting is the difference between a review and a rubber stamp.
Keyword casing. Uppercase keywords (SELECT, FROM, WHERE) against lowercase identifiers is the dominant convention because it makes the query's skeleton visible at a glance. Some teams go all-lowercase and lean on syntax highlighting. Either is fine; pick one, encode it in the formatter, never discuss it again.
Clause-per-line and indentation. Every major clause starts a line. JOINs get their own lines with ON conditions indented. Subqueries indent one level. CTEs — the WITH blocks that make modern analytics queries readable at all — get separated so each reads like its own mini-query. When a CTE chain is formatted properly, you can read a pipeline top to bottom the way you'd read a script.
The comma war. Leading commas (, revenue) make columns easy to comment out and produce cleaner diffs; trailing commas read more naturally. This argument is older than some of the people having it. A formatter's real gift is that it ends the argument: the setting exists, someone picks it, everyone moves on.
Our free SQL formatter does all of the above in the browser — paste, format, copy. No signup, and your query never leaves the page, which matters more than people think when the query contains table names and business logic you'd rather not mail to a stranger's server.
SQL is a family of dialects pretending to be a standard. PostgreSQL quotes identifiers with double quotes, MySQL with backticks, SQL Server with brackets. BigQuery allows trailing commas in SELECT lists; most others don't. Snowflake, Redshift, and BigQuery each grew their own semi-structured syntax (FLATTEN, UNNEST) that a naive formatter mangles. A dialect-aware formatter parses your flavor instead of guessing — if you write queries by hand and want them generated instead, the AI SQL generator speaks the major dialects and emits formatted output from a plain-English description.
Honesty section. A formatter changes whitespace, not the query plan. Your beautifully indented query still scans the whole table if there's no index, still explodes rows on that fan-out join, still times out on the correlated subquery that should've been a window function. Formatting makes those problems visible — which is genuinely half the battle — but fixing them is query work: read the EXPLAIN output, check the join keys, rethink the access pattern. Format first so you can see; then optimize what you can now read.
Formatting discipline that depends on humans remembering lasts about two sprints. The teams that keep clean SQL wire it into the loop: format-on-save in the editor, a formatter pass in CI, a pre-commit hook. And increasingly, it's not humans writing the first draft anyway — it's agents. QADIR OS runs agents locally with database and file access, so "format every query in the repo, flag the ones with cartesian joins" is a job you schedule on your own machine, not a service you upload your schema to.
Stop reading one-line SQL. Paste your query into the free SQL formatter — instant structure, nothing leaves your browser. Need the query written for you? Try the AI SQL generator, or join early access for agents that handle the whole pipeline. No card required.