SQL Formatter

SQL ignores whitespace. A query written as one 400-character line and the same query spread over twenty lines are identical to the database — it parses both into exactly the same plan. Formatting is entirely for the reader. It takes a query whose structure is buried in a wall of text and puts that structure back on the screen: one clause per line, one column per line, nested queries indented inside their parentheses.

1select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=1 and u.plan='pro' group by u.id,u.name having count(o.id)>2 order by orders desc;2 3SELECT4  u.id,5  u.name,6  COUNT(o.id) AS orders7FROM users u8LEFT JOIN orders o ON o.user_id = u.id9WHERE u.active = 110  AND u.plan = 'pro'11GROUP BY u.id, u.name12HAVING COUNT(o.id) > 213ORDER BY orders DESC;

Nothing changed except whitespace and the casing of keywords. The second version runs the same, returns the same rows and takes the same time — but you can see in one pass that there is a left join, two filters and a group, and you could point at the line you wanted to change. The freedom runs both ways: the SQL minifier collapses the formatted version back to a single line for embedding in code, and the database still reads it identically.

Everything here runs in your browser. The queries people paste into a formatter carry table names, column names and often real values, so nothing is uploaded, stored or logged.

Because unformatted SQL hides exactly the things that go wrong with it. Almost every SQL bug is a structural one — a join condition that got attached to the wrong table, a filter that ended up in the WHERE instead of the ON, a parenthesis one position out — and all of them are invisible in a single line and obvious once the structure is on separate lines.

• Reviews stop being archaeology. A reviewer can see which clauses exist and which columns are selected without rebuilding the query in their head first.
• Diffs shrink to the actual change. With one column per line, adding a column is a one-line diff, whether in a pull request or a diff checker. On a single-line query, it is a change to the whole query and nobody can see what moved.
• Copied queries become readable.SQL pulled out of an application log, an ORM’s debug output or a slow-query report arrives as one long line. Formatting is the first step to understanding it.
• Dangerous statements announce themselves. A DELETE with no WHERE is easy to miss in a paragraph of text and hard to miss on its own line — and this tool warns about it besides.
• Teams stop arguing about style. One agreed set of options, applied by a tool, ends the discussion about where the commas go.
• Learning gets faster. Clause order is one of the first things to internalise about SQL, and seeing every query laid out in that order teaches it far quicker than reading prose about it.

“Standard SQL” is aspirational. Every engine extends the grammar, and the extensions that matter most to a formatter are the ones that change what a character means — because reading a quote wrongly turns a string into a name, or a name into a string, and everything after it is wrong too.

1SELECT `order` FROM `user`;     -- MySQL, MariaDB, BigQuery2SELECT "order" FROM "user";     -- PostgreSQL, Oracle, SQLite3SELECT [order] FROM [user];     -- SQL Server4SELECT "order" FROM "user";     -- ANSI SQL

Pick an engine from the options, or leave detection on and let the query speak for itself. Detection scores markers rather than trusting any single one: a query with nothing distinctive in it stays ANSI instead of being guessed at.

Keyword formatting

Keywords, types and built-in function names can be uppercased, lowercased or capitalised. Uppercase is the long-standing convention and the default: it separates the words SQL owns from the words your schema owns, which is most of what makes a query skimmable. Identifiers are a separate setting and default to being left exactly as written — and a quoted name is never recased at all, since quoting it is precisely how you asked for its case to be kept.

Indentation

Two spaces, four spaces or tabs, applied to clause contents, nested queries and table definitions. A subquery is indented inside its parentheses so its own clauses read as a query in their own right, and the closing parenthesis returns to the level of the line that opened it.

1SELECT name2FROM users3WHERE id IN (4  SELECT user_id5  FROM orders6  WHERE total > 5007);

Clause alignment

Turn on align clauses for the river style, where the clause keywords share a right edge and their contents hang one column past it. Some people read a query by scanning that keyword column; for them the river is much faster than a left-aligned list.

1  SELECT2         u.id,3         u.name4    FROM users u5    JOIN orders o ON o.user_id = u.id6   WHERE u.active = 17         AND o.total > 108GROUP BY u.id9ORDER BY u.name;

Syntax highlighting

Keywords, types, functions, table names, column names, strings, numbers, parameters and comments each get their own treatment, in both panels and in both light and dark themes. Table names are picked out from column names by position — a name after FROM, JOIN, INTO, UPDATE or TABLE is a table — so the shape of a join chain is visible without reading it.

Validation

Every issue comes with a line, a column, a caret pointing at the exact character and something to do about it. What it checks is deliberately bounded to what can be established from the text with certainty:

• Unterminated strings, comments and quoted names. The most destructive class of error, because everything after the opening quote is being read as something it is not.
• Unbalanced parentheses. Reported against the one that has no partner, not against the end of the query.
• Trailing and doubled commas, and a SELECT with no columns at all.
• UPDATE or DELETE with no WHERE, which is valid SQL and applies to every row in the table.
• A SELECT whose clauses imply a table it never names. SELECT 1 is fine; SELECT u.id WHERE … is not.
• Mistyped keywords, allowing one edit including a swap of neighbouring letters — which is how FORM happens.

It is a linter, not a database. It cannot tell you that a table does not exist or that a column is misspelled, and it does not pretend to.

Seven statements cover almost everything anyone writes by hand. Each one has a shape, and formatting exists to make that shape visible.

Indent to show nesting, not to decorate

Indentation should mean one thing: this is inside that. A subquery indented inside its parentheses, a column indented under the clause that selects it, a procedure body indented inside its BEGIN. Indentation used for anything else — lining up equals signs, centring things — breaks the moment a name gets longer.

Alias tables, and alias them consistently

A short alias used everywhere beats a long table name repeated everywhere, and a consistent alias beats a short one. If users is u in one query it should be u in all of them. Always qualify columns once there is more than one table in play: id in a three-way join is a question, and u.id is an answer.

1SELECT2  u.id,3  u.email,4  o.total5FROM users u6INNER JOIN orders o ON o.user_id = u.id7WHERE u.active = 1;

Give every join its own line, and its condition beside it

A join is two facts — which table, and how it connects — and they belong together on one line. Read down the left edge and you have the whole join chain. Put the filtering conditions in the WHERE and the joining conditions in the ON: mixing them is legal, changes the result for outer joins, and is the single most common cause of a query that returns nearly the right rows.

Name things for the person who reads them next

Plural table names or singular ones, snake_case or camelCase — it matters far less which you pick than that you pick one. Avoid reserved words as names: a column called order or user has to be quoted forever afterwards, in every query, by every person who touches it. Name a computed column for what it means — order_count, not c.

Optimise for reading

A query is written once and read for years. Prefer an explicit column list to SELECT *, so the query keeps returning the same shape after somebody adds a column. Break a query that has grown past comprehension into CTEs with names that say what each step produces. Leave a comment for the why — the business rule behind an odd-looking filter — and let the formatting carry the what.