SQL Formatter

What this does

Takes a query written as one long line — the kind you pull out of an ORM log or a stack trace — and lays it out with each clause on its own line and its operands indented beneath. Keywords are uppercased by default, the indent is yours to set between 1 and 8 spaces, and there are eleven dialects to pick from. The formatter is the sql-formatter library, loaded into the page on demand, so the query is parsed on your machine and never sent to a server.

How do I format a SQL query?

1. Paste the query into the SQL box, replacing the sample.
2. Choose the Dialect that matches your database.
3. Adjust Indent and the Uppercase keywords checkbox if you want a different house style.
4. The Formatted box updates as you type — the Format button is there for a manual re-run.
5. Click Copy to take the result.

select a,b from t where c=1

SELECT
  a,
  b
FROM
  t
WHERE
  c = 1

Which SQL dialects are supported?

Standard SQL (the default), PostgreSQL, MySQL, SQLite, MariaDB, MS SQL Server (T-SQL), BigQuery, Amazon Redshift, Snowflake, IBM DB2 and Oracle PL/SQL. The choice is not cosmetic — each dialect brings its own reserved words, operators, quoting rules and parameter syntax, so a query that fails to tokenize under one will often format cleanly under the right one.

Why does my query give a parse error?

This is a real parser, not a regex reflow, so anything it cannot tokenize stops it and the message appears next to the buttons. By far the most common cause is leaving the dialect on Standard SQL while using something dialect-specific. Named placeholders are the classic case:

SELECT id FROM t WHERE x = :name

  dialect "Standard SQL"  →  Parse error: Unexpected ":name" at line 1 column 28
  dialect "PostgreSQL"    →  formats fine

The library's own error text even suggests picking a more specific dialect. Other triggers are genuinely incomplete SQL (an unclosed parenthesis reports a parse error at the end of input) and vendor extensions the parser does not model. When that happens the previous formatted output stays on screen — check the status line rather than assuming the result refreshed.

Does formatting change what my query does?

No. It only moves whitespace and changes the case of reserved words. Comments survive — a /* … */ stays attached to the token it preceded and a -- comment stays at the end of its line. Identifiers, string literals and numbers are left exactly as written, so MyTable does not become MYTABLE, which matters on the databases where quoted identifiers are case-sensitive. It also does not validate anything beyond syntax: a query referencing a table that does not exist formats happily.

Should SQL keywords be uppercase?

It is a style choice with no effect on execution — SQL keywords are case-insensitive everywhere. Uppercase is the older convention and makes the clause structure jump out of a wall of snake_case identifiers; lowercase is common in modern codebases that treat keywords as scaffolding. The checkbox flips the whole query either way, so it is also a quick way to normalise a file that has drifted between the two. If you are cleaning up other artefacts from the same log line, the JSON formatter handles the payload, regex tester helps you pull queries out in bulk, and CSV to JSON converts the result set.