Format SQL queries

Q: Does it keep my comments?

Yes. Both -- line comments and / / block comments are kept. A comment inside a clause may move to its own line.

Q: Does it handle placeholders like ? and $1?

Yes, in the dialects that use them: ? in MySQL, $1 in PostgreSQL, @id in SQL Server and :id in Oracle. A placeholder from a different dialect is reported as an error, so pick the dialect your queries use (in Standard SQL only ? works). Template placeholders such as ${id} or {{id}} are not SQL, and are not read in any dialect.

Paste a query, pick your database, and get it laid out with one clause per line. Your SQL never leaves this tab.

Your text is processed in this tab and never uploaded

Options

Dialect

Pick your database

Keywords

Indent

More options

Layout

AND and OR go

Blank lines between queries

Keep (...) on one line up to

chars

Tight operators

Writes a=1 instead of a = 1.

SQL

0 characters, 0 lines Your text stays in this tab.

Formatted SQL

This lays a query out. It does not run it or know your tables, so it cannot tell you that a table or column does not exist. It does stop on text it cannot read, such as an unclosed quote or bracket.

At a glance

What it does: Lays out SQL queries with one clause per line and indented subqueries, as you type.
Dialects: 20, including PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, BigQuery, Snowflake and Redshift.
Options: UPPER, lower or as written keywords, 2 or 4 spaces or tabs, aligned layouts, AND and OR at the line start or end, and tight operators.
Kept: Comments, text inside quotes, function names and your table and column names, except a name that is also an SQL keyword (see below).
Errors: Unclosed quotes and unmatched brackets are reported with a line and column.
Not checked: It does not run the query or know your tables, so it cannot tell you a name is wrong.
Privacy: Runs in your browser tab. Your SQL is never uploaded.

How to do it

1
Paste your SQL
Paste one or more statements into the left box, drop a .sql file on it, or press Example.
2
Pick your dialect
Choose the database you write for, then the keyword case and the indent.
3
Read the result
The formatted query updates as you type. If the text cannot be read, you get the line, the column and a likely cause.
4
Copy or download
Copy the result or download it as formatted.sql.

Pick the dialect that matches your database

SQL is a standard with many accents. The dialect tells the formatter which words are keywords, how names are quoted, and which operators exist, so it can read your query the way your database would.

MySQL and MariaDB quote names with backticks, as in `order`. SQL Server uses square brackets, as in [order].
PostgreSQL has the :: cast, as in price::int, and numbered placeholders such as $1.
BigQuery uses backticks around project and table paths.
Oracle (PL/SQL) and SQL Server (T-SQL) add procedural keywords such as BEGIN, DECLARE and WHILE.

If you are not sure, start with Standard SQL. If the formatter reports an error on a query that works in your database, switch to the matching dialect before assuming the query is wrong.

How the layout works

Each main clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY) starts on its own line, and the items under it are indented. Select columns go one per line. AND and OR start new lines, either at the start or the end of the line as you choose. Subqueries and CASE expressions are indented as blocks. Several statements are separated by blank lines, and you can set how many.

Short expressions in brackets, such as IN (1, 2, 3) or varchar(50), stay on one line. Under More options you can change how long a bracketed expression may be before it is split. The Aligned layouts line the keywords up in a column.

What the formatter changes and what it does not

It changes white space, and the case of keywords if you ask for it. Keyword case applies to SQL keywords. Function names and text inside quotes are not changed, and neither are most table and column names. A name that is also a keyword in the dialect, such as year, end, user or values, is read as a keyword: it changes case with the Keywords setting, and a word like values can also start a new line. Choose Keep under Keywords to leave every word as you wrote it, or put such a name in quotes. Comments, both -- line and /* block */, are kept.

It does not run your query, rename anything, or reorder clauses. Because it does not know your schema, a misspelled column passes. Run the query on a copy of your data when you need to know that it works.

Procedural code, such as loops and variables in T-SQL or PL/SQL, is read only roughly, so expect a less tidy layout for those blocks.

Questions people ask

Which dialect should I choose?

Choose the database you run the query on. If you are not sure, or the query is plain SELECT and JOIN that every database accepts, use Standard SQL.

Does it change what my query does?

It only changes layout and, if you choose, the case of keywords. Text inside quotes is never changed, and names of tables and columns are left alone, with one exception: a name that is also an SQL keyword, such as year or end, changes case along with the keywords. Choose Keep under Keywords to avoid that. Check the formatted query on non critical data before relying on it, as with any automated edit.

Does it keep my comments?

Yes. Both -- line comments and /* */ block comments are kept. A comment inside a clause may move to its own line.

Why do I get a parse error?

The formatter stops on text it cannot read. The usual causes are a quote or bracket that is never closed, or syntax from a different database. The message gives the line and column. If the query works in your database, try the matching dialect.

Does it handle placeholders like ? and $1?

Yes, in the dialects that use them: ? in MySQL, $1 in PostgreSQL, @id in SQL Server and :id in Oracle. A placeholder from a different dialect is reported as an error, so pick the dialect your queries use (in Standard SQL only ? works). Template placeholders such as ${id} or {{id}} are not SQL, and are not read in any dialect.

Is my SQL uploaded?

No. The SQL formatter loads into your browser tab and runs there. Your queries, which often contain table names and values from real systems, are never sent anywhere.