Formatters

SQL Formatter

Beautify SQL queries with dialect-aware formatting.

Input
SQL input
Output
Result
Options

Spaces per level of nesting.

About this tool

A query written as one long line is hard to review and harder to debug. Formatting puts each clause on its own line, indents subqueries and joins to show nesting, and aligns the parts that should be compared visually, which is how you spot a missing join condition or a misplaced parenthesis.

Formatting is dialect-aware, because SQL is not one language. PostgreSQL, MySQL, T-SQL, BigQuery and Oracle differ in their keywords, quoting and functions, so picking the right dialect gives noticeably better results than generic formatting.

How to use it

  1. Paste or upload your sqlDrop a file onto the input pane, use the file picker, or paste the text directly.
  2. Adjust the options if neededThe defaults suit most input; open Options to change the behaviour.
  3. FormatPress Format, or use Ctrl+Enter (Cmd+Enter on macOS).
  4. Copy or downloadCopy the result, or download it as a .sql file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

A single-line query expanded

Input

select u.id, u.name from users u join orders o on o.user_id = u.id where u.active = true order by u.name

Output

SELECT
  u.id,
  u.name
FROM
  users u
  JOIN orders o ON o.user_id = u.id
WHERE
  u.active = TRUE
ORDER BY
  u.name

Each clause gets its own line, and the join condition stays attached to its join.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Why the dialect setting matters
Each dialect has keywords and syntax the others lack, MySQL backtick quoting, T-SQL square brackets, PostgreSQL's :: casts and dollar-quoted strings, BigQuery's array and struct syntax. Choosing correctly means those are recognised as syntax rather than treated as opaque text.
Keyword casing is a convention, not a requirement
SQL keywords are case-insensitive, so casing is purely for readability. Uppercase keywords against lowercase identifiers is the long-standing convention and the default here, because it makes structure scannable at a glance. Choose "preserve" if your team has settled on something else.
Formatting never changes what a query does
Only whitespace and keyword casing change. String literals, identifiers and comments are left exactly as written, including whitespace inside a quoted string, which is data. The formatted query is semantically identical to the original.
Multiple statements and tabular alignment
A script containing several statements separated by semicolons is formatted as a whole, with blank lines between statements. The optional tabular style aligns clause keywords in a left-hand column, which some teams prefer for long SELECT lists.
What the formatter cannot do
It formats; it does not validate. A query with a genuine logic error still formats cleanly. Syntax too malformed to tokenise produces an error, but that is a parsing limit rather than a correctness check, use your database's EXPLAIN to verify a query actually works.

Limitations

  • Formats rather than validates; it cannot tell you whether a query is correct.
  • Very unusual vendor extensions may not be recognised even with the right dialect selected.
  • Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

Does formatting change my query results?
No. Only whitespace and keyword casing change, and SQL keywords are case-insensitive. String contents are untouched.
Which dialect should I pick?
The one your database uses, so dialect-specific syntax is recognised. Standard SQL works acceptably for ordinary queries but may not handle vendor extensions well.
Does this validate my SQL?
No. It formats syntactically recognisable SQL. A query can format perfectly and still be wrong, use EXPLAIN against your database to check it.
Is my query sent to a server?
No. Formatting runs in your browser, which matters because queries often contain table names, schema details or literal values you would not want to share.

Related tools