SQL tolerates almost any layout, which is exactly why real world queries end up in so many different shapes: some teams write everything on one line, some indent every clause, some put commas at the start of a line and some at the end. That inconsistency makes a query generated by an ORM, exported from a database tool, or pasted from a colleague's message noticeably harder to review than one formatted according to a single consistent convention.
Formatting happens entirely in your browser using a tokeniser built for this page. A query touching a production customers or payments table never has to leave your machine to get formatted, which matters since a query is often the clearest single artifact showing exactly what data a piece of code reads or writes.
What this sql formatter changes
Every SQL keyword, SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, INSERT INTO, VALUES, UPDATE, SET and DELETE FROM among them, is uppercased for visual consistency, since mixed case keywords are one of the most common small inconsistencies across a codebase with more than one author. As a sql indentation tool it also puts major clauses each on a new line, and indents conditions joined by AND or OR inside a WHERE clause consistently so a long filter is easy to scan top to bottom instead of reading as one dense line.
Table names, column names, string literals and numeric values are left exactly as written, since changing the case of an identifier can matter in a case sensitive database and changing the case of a string literal changes the data the query matches. Only keywords and whitespace are affected.
- Uppercases every recognised SQL keyword, including multi word ones like GROUP BY and ORDER BY.
- Puts each major clause, SELECT, FROM, WHERE, JOIN, GROUP BY and ORDER BY, on its own line.
- Indents AND and OR conditions inside a WHERE clause for readability.
- Aligns JOIN and its ON condition so a multi join query reads clearly top to bottom.
- Never changes a table name, column name, string literal or number.
Clause based line breaking across statement types
A SELECT statement breaks after SELECT, before FROM, before each JOIN, before WHERE, before GROUP BY, before HAVING and before ORDER BY, which mirrors how most SQL style guides recommend formatting a query by hand. An INSERT statement puts the column list and the VALUES list each on their own indented block, which is the layout that makes it fastest to check that a column list and its corresponding values line up correctly.
An UPDATE statement puts each SET assignment on its own line when there is more than one, and a DELETE statement follows the same FROM and WHERE line breaking as a SELECT. Across all four statement types the underlying logic is the same: break before a clause keyword, indent what belongs inside that clause, and never touch anything that is not a keyword or whitespace.
Why this sql formatter uppercases keywords but not identifiers
Choosing to uppercase SQL keywords next to lowercase or mixed case table and column names is the most common convention in professional SQL, since it creates immediate visual contrast between the fixed vocabulary of the SQL language and the specific names your schema uses. A reader scanning the query can separate structure from content almost instantly.
This tool never touches an identifier's case because SQL databases vary in whether they are case sensitive for table and column names. Changing table_name to TABLE_NAME could silently break a query against a case sensitive database, so identifiers are always preserved byte for byte, and only the fixed set of recognised SQL keywords is uppercased.
How this sql formatter works under the hood
The tool tokenises the SQL text first, splitting it into keywords, identifiers, string literals, numbers and punctuation while respecting quoted strings so a keyword that happens to appear inside a string literal, such as the word from inside a text value, is never mistaken for actual SQL syntax. It then walks the token stream applying a set of line breaking and indentation rules keyed to whichever clause keyword it just saw.
Because this runs as a tokeniser rather than a full SQL parser, it does not validate that a query is semantically correct or check it against a specific database dialect's exact grammar. It formats syntactically ordinary SQL reliably, and for a genuinely unusual construct, some vendor specific extension for example, it falls back to preserving the original spacing around that construct rather than guessing.
How to format a SQL query
- 1
Add your query
Paste a SELECT, INSERT, UPDATE or DELETE statement into the input box.
- 2
Format
Run the formatter to uppercase keywords and break the query into indented clauses.
- 3
Review the result
Check that joins, conditions and the column or value list read clearly top to bottom.
- 4
Copy or download
Copy the formatted query to your clipboard or download it as a .sql file.
Related tools worth bookmarking
Sources and further reading
Frequently asked questions
Common questions about the sql formatter.
No. Only whitespace and keyword casing are changed. Table names, column names, string literals, numbers and the logical structure of the query are left exactly as written, so the formatted query returns identical results to the original.
No, only recognised SQL keywords are uppercased. Identifiers are left in their original case, since some databases are case sensitive for table and column names and changing that case could break the query against those systems.
It tokenises and formats syntactically ordinary SQL reliably, but it is not a full parser and does not check a query against a specific database's grammar or confirm that referenced tables and columns actually exist. Use your database's own query validation for that.
Yes. INNER JOIN, LEFT JOIN, RIGHT JOIN and FULL JOIN are all recognised, and each JOIN clause along with its ON condition is placed on its own line so a query with several joins stays readable instead of running together as one dense block.
No. Formatting runs entirely in your browser using a local tokeniser. Your query, including one that references production table or column names, is never transmitted, stored or seen by anyone but you.
Yes. INSERT statements get their column list and VALUES list formatted as separate indented blocks, and UPDATE statements get each SET assignment placed on its own line when there is more than one, following the same clause based approach used for SELECT and DELETE statements.