Raw SQL
paste or type · or drop a .sql file
Formatted SQL

Why format SQL queries?

Unformatted SQL is notoriously hard to read, especially complex queries with multiple JOINs, subqueries, or CTEs. Consistent formatting makes it easier to spot errors, understand query structure at a glance, and collaborate with teammates.

Formatted SQL is also easier to diff in version control: a consistently formatted file produces clean, meaningful diffs instead of noise from whitespace changes. This formatter applies standard indentation, aligns clauses, and optionally uppercases SQL keywords.

SQL dialect differences

While standard SQL (ISO/ANSI) is the foundation, each database engine extends or modifies the syntax. Selecting the right dialect ensures the formatter applies correct keyword sets and quoting conventions.

MySQLBacktick identifiers, functions like GROUP_CONCAT
PostgreSQLDouble-quote identifiers, dollar-quoted strings, RETURNING
SQLitePermissive — accepts many variants, ignores type constraints
T-SQLSquare-bracket identifiers, TOP instead of LIMIT

Tips for clean SQL

Uppercase SQL keywords and lowercase identifiers is the most common convention. Use meaningful table aliases (u for users, o for orders) rather than single letters. Break long SELECT lists onto separate lines, one column per line.

Place each JOIN on its own line with the ON condition indented beneath it. Use CTEs (WITH … AS) to name and reuse complex subqueries instead of nesting them. Add trailing commas rather than leading ones. Run EXPLAIN or EXPLAIN ANALYZE on slow queries to understand the execution plan.