SQL Formatter

How to use it

1. 1Paste your text into the box marked "Your SQL"Paste a query — a long one with joins and subqueries is where this earns its keep. Everything happens inside your browser — nothing is uploaded, so there is nothing for us to store, log or lose.
2. 2Read the result as it updatesThere is no button to press. The formatted query appears immediately. The output recomputes every time you change the text or one of the options above it.
3. 3Choose your DialectGeneric, PostgreSQL or MySQL / MariaDB. It changes how quoting and dialect-specific keywords are handled, so picking the right one avoids a formatter that mangles an identifier it did not recognise.
4. 4Set the Keywords caseUPPERCASE, lowercase or as written. Leaving them as written is the right choice when you are tidying somebody else's file and do not want a diff full of case changes.
5. 5Read it as formatting onlyThis lays a query out; it does not check that it is valid against your schema, and it never changes what the query does.
6. 6Copy or download the resultThe buttons under the output put it on your clipboard or save it as a file, and each one says exactly what it will copy or download. Any note about something the tool changed or deliberately left alone is shown with the result rather than hidden.

About this tool

Format a SQL query into the layout experienced people read fastest: one major clause per line, select-list items and conditions indented beneath their clause, subqueries indented inside their parentheses, keywords cased consistently.

The formatter is layout-only by design. Tokens are never added, removed or reordered — the single change beyond whitespace is keyword casing, and only when you choose it. And it never executes anything: this is text formatting in your browser, not a database connection. There is no engine here to run a query against.

Understanding the result

Major clauses (SELECT, FROM, WHERE, GROUP BY, each JOIN…) start their own lines. AND, OR and ON are indented one level under the clause they belong to, which is what makes a long WHERE readable.

Function arguments and IN lists stay inline; a parenthesis that opens a subquery gets a full indented block instead. Comments survive on their own lines.

The dialect matters more than it looks: it sets the quoting rules the tokenizer applies. Backticks and # comments are MySQL, [brackets] are SQL Server, $$dollar quotes$$ and nested block comments are PostgreSQL, and a backslash inside a string is an escape in MySQL but a literal character in PostgreSQL. Generic accepts all of them at once — the right default for a query of unknown origin.

Example

select u.id, count(*) as n from users u left join orders o on o.uid = u.id where u.active = 1 group by u.id order by n desc

SELECT u.id,
  COUNT(*) AS n
FROM users u
LEFT JOIN orders o
  ON o.uid = u.id
WHERE u.active = 1
GROUP BY u.id
ORDER BY n DESC

Limitations

• This formats; it does not validate SQL grammar. A query with a typo in a keyword formats as if the typo were an identifier — only lexical errors (an unclosed string, comment or parenthesis) are reported, each with its position.
• Type names (int, varchar…) are treated as identifiers, so keyword casing does not touch them.
• Procedural blocks (stored procedures, triggers, BEGIN…END bodies) are formatted with the same clause rules, which is serviceable but not specialised — a dedicated PL/pgSQL or T-SQL formatter will lay those out better.
• Very long queries format fine, but this is a reading aid, not a linter: it will not warn about SELECT *, missing indexes or Cartesian joins.

Questions