SQL Formatter
Format SQL with keyword casing and clause indentation
SQL formatter: style conventions, execution order, and what reformatting can silently get wrong
What formatting does, and what it does not
Formatting only does layout: it line-breaks by clause, indents by nesting level, and optionally uppercases keywords. It does not:
- Validate syntax. It is not a parser; it reorders by keyword and parentheses. So a SQL statement with an obvious syntax error can still be "formatted" into a tidy-looking output. Correctness has to come from the database or a dedicated linter.
- Improve performance. Layout has nothing to do with the execution plan. A slow query is fixed with indexes, statistics, and plan analysis — not with newlines.
- Understand semantics. It does not know that a
selectappearing inside a string literal should be treated as ordinary text; this distinction is the key test of whether an implementation is any good.
The last point deserves a concrete example: in SELECT 'select from where' AS x, the 'select from where' is a string value and must not be treated as clauses. An implementation that only regex-matches keywords would mangle the quoted content. This tool skips the inside of string literals (single quotes, double quotes, and backtick-wrapped identifiers), so their contents are left untouched.
Style conventions
| Choice | Convention | Reason |
|---|---|---|
| Keyword casing | UPPER SELECT | Distinguishes keywords from identifiers and function names; easier to scan in long queries |
| Indentation | 2 or 4 spaces | Team uniformity is what counts; do not mix tabs and spaces |
| Main-clause line breaks | FROM, WHERE, GROUP BY each on its own line | Makes the scope of each clause visible at a glance |
| Comma position | Leading (, col) or trailing | A leading "trailing comma" yields cleaner diffs when adding or removing columns |
| JOIN alignment | Each JOIN on its own line, indenting its ON | Multi-table joins are where logic is most easily misread |
Uppercasing keywords is the most widespread convention, but it is not a hard rule — some style guides demand all-lowercase (because SQL itself is not case-sensitive about keywords, so you save one Shift per word). What matters is team consistency; mixing is what hurts readability the most. The tool exposes a toggle so you can follow your own habit.
The written order and the real execution order differ
This is the single most useful thing for understanding complex queries: the order you write the text in is not the order the database computes it.
| Written order | Execution order |
|---|---|
| SELECT | 1. FROM (determine the data source) |
| FROM | 2. JOIN / ON (joins) |
| WHERE | 3. WHERE (filter rows) |
| GROUP BY | 4. GROUP BY (grouping) |
| HAVING | 5. HAVING (filter groups) |
| ORDER BY | 6. SELECT (compute output columns) |
| LIMIT | 7. DISTINCT / ORDER BY / LIMIT |
From this you can derive several common confusions directly:
- Why you cannot use a SELECT alias inside WHERE. WHERE runs before SELECT, so the alias does not yet exist. (You can use it in ORDER BY, because that runs last.)
- Why HAVING can filter aggregated results but WHERE cannot. WHERE runs before grouping, HAVING after it.
- Why an aggregate function inside WHERE throws an error. Aggregation happens after WHERE.
Dialect differences across databases
Formatting does not change a statement, but when you read a formatted SQL you should watch for dialect-driven differences:
| Difference | What to watch |
|---|---|
| Identifier quoting | MySQL uses backticks, PostgreSQL / Oracle use double quotes, SQL Server uses square brackets |
| Pagination | LIMIT / OFFSET (MySQL, PostgreSQL, SQLite), FETCH FIRST (standard SQL, Oracle 12c+, SQL Server), ROWNUM (old Oracle) |
| String concatenation | Both CONCAT() and || have varying support |
| Escape inside quotes | Doubling the single quote as '' is standard; a backslash escape is on by default in MySQL but does not apply in PostgreSQL standard strings |
If you are migrating across databases, formatting alone will not reveal this — you need a dedicated dialect-conversion tool or manual review. The formatted output is not a compatibility validation.
How to use the tool
Paste SQL, click format, and optionally tick "uppercase keywords". The output line-breaks by clause and indents nested structures (subqueries, bracketed conditions). It is a reversible, pure-layout operation; the original meaning is unchanged. Use it to unify format before review, to untangle a long query that was compressed onto one line in a log, and to read someone else's single-line SQL. Everything runs locally in your browser, so statements containing production table and column names are never uploaded.
FAQ
Will keywords inside strings be mishandled?
No. The tool first protects single-quoted strings and comments with placeholders, then restores them after formatting, so string and comment contents stay intact.
Which SQL dialects are supported?
Common SQL clauses are recognized; typical MySQL / PostgreSQL / SQLite syntax works. A few dialect-specific constructions may not wrap perfectly.
Does formatting change the query result?
No. It only adjusts whitespace and line breaks and does not alter any semantics.