Why format SQL?
Raw SQL from logs, ORMs, or copied query builders is often a single unreadable line. Formatted SQL with consistent keyword casing, one clause per line, and indented conditions is dramatically easier to read, debug, and review in pull requests. Consistent formatting also makes it easier to spot performance issues — a missing index hint, an unintentional Cartesian join, or a WHERE clause that applies to the wrong table become visible when the query is laid out clearly.
What this formatter does
The formatter uppercases all SQL keywords (SELECT, FROM, WHERE, JOIN, etc.), places each major clause on its own line, indents AND/OR conditions under WHERE, and breaks the SELECT column list onto individual indented lines when there are multiple columns. It works with standard SQL as used by MySQL, PostgreSQL, SQLite, and SQL Server — dialect-specific syntax (stored procedures, window functions) will be formatted as best as possible but some edge cases may need manual adjustment.
Supported keywords
SELECT, FROM, WHERE, JOIN (all variants: LEFT, RIGHT, INNER, OUTER, FULL, CROSS), ON, AND, OR, GROUP BY, ORDER BY, HAVING, LIMIT, OFFSET, UNION, INSERT INTO, VALUES, UPDATE, SET, DELETE FROM, CREATE TABLE, ALTER TABLE, DROP TABLE, CASE/WHEN/THEN/ELSE/END, as well as aggregate functions COUNT, SUM, AVG, MIN, MAX and AS, DISTINCT, IN, BETWEEN, LIKE, IS NULL, IS NOT NULL.
Tips for best results
The formatter assumes standard SQL syntax. Comments (-- and /* */) in the middle of a query may affect formatting. Sub-queries in parentheses are currently formatted as inline text. For very long or complex queries with deeply nested subqueries, the output may not be perfectly indented — treat it as a starting point and adjust the nesting manually if needed.