Readable SQL in the dialect you write
This SQL formatter takes a query of any length, even several statements at once, and indents it consistently: one clause per line, columns and conditions lined up, keywords in the case you prefer. It understands the syntax of more than fifteen dialects, from PostgreSQL, MySQL and SQL Server to BigQuery, Snowflake and Oracle PL/SQL, so dialect-specific operators, quoting and placeholders are kept intact. Switch to Minify to turn a query back into a single line for a config file or a string in your code. Everything runs in your browser; your queries are never uploaded.
How to format a SQL query
- 1Paste your SQL into the left pane, or start from the sample query.
- 2Choose the dialect the query is written for. Standard SQL works for most simple queries; picking the right dialect matters for things like PostgreSQL's
::casts, MySQL's backtick identifiers or SQL Server's[brackets]. - 3Set the keyword case and indentation, and open More options for data type and function case, tabular indentation, where
AND/ORgo and the blank lines between statements. - 4The formatted query appears on the right as you type. If the query cannot be parsed, the line and column of the problem are shown.
- 5Copy the result, download it as a
.sqlfile, or choose Minify to collapse it to one line.
Why format SQL?
SQL is written once and read many times: in code review, in a slow-query log, in a migration someone has to debug at 2 a.m. A query generated by an ORM or pasted from a log usually arrives as one enormous line. Putting each clause on its own line and indenting subqueries makes its structure visible: which tables are joined, on what, and which conditions apply where.
Consistent formatting also makes diffs smaller. When everyone on a team formats queries the same way, a changed condition shows up as one changed line instead of a reflowed paragraph.
Formatting options explained
- Keyword case
- UPPER makes SELECT, FROM and WHERE stand out from table and column names, the most common convention. lower suits teams who find upper case noisy. Preserve leaves keywords as you typed them.
- Indentation
- Two or four spaces, or tabs. Tabular styles instead pad keywords into a fixed-width column so that the expressions line up after them.
- AND / OR position
- Before puts each logical operator at the start of the line, which makes it easy to comment one condition out; after leaves it at the end of the previous line.
- Expression width
- Parenthesised expressions shorter than this many characters stay on one line; longer ones are broken up.
- Dense operators
- Writes a+b instead of a + b. Compact, but harder to read.
Choosing the right dialect
SQL dialects disagree about more than you might think: how identifiers are quoted ("name", `name` or [name]), what a placeholder looks like (?, $1, :name, @param), and which words are reserved. The formatter uses a separate grammar for each dialect, so it does not mistake a PostgreSQL $$ function body or a MySQL # comment for something else.
If you see a parse error for a query you know is valid, the dialect is the first thing to check. Standard SQL is deliberately strict and does not know every vendor extension.
Minifying SQL
Minify does the opposite of formatting: it removes comments and collapses all whitespace to single spaces, giving one line you can paste into a YAML file, an environment variable or a string literal. String literals, quoted identifiers and dollar-quoted bodies are copied exactly, so a value like 'two spaces' keeps both spaces. Optimizer hints written as /*+ … */ and MySQL's executable /*! … */ comments are kept, because they change how the query runs.
Working with JSON instead? The JSON formatter does the same for JSON documents, and the code minifier handles CSS, JavaScript and HTML.
Frequently asked questions
- Is my SQL sent to a server?
- No. Formatting and minifying run entirely in your browser, so queries containing table names, customer data or credentials never leave your device.
- Which SQL dialects are supported?
- Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Amazon Redshift, Spark SQL, Hive, Trino and Presto, DuckDB, ClickHouse, IBM Db2 and Db2 for IBM i, SingleStoreDB, TiDB and Couchbase N1QL.
- Does formatting change what my query does?
- No. Only whitespace and, if you choose, the letter case of keywords, data types and functions change. Identifiers in quotes and string literals are never altered. Changing the case of unquoted identifiers is safe in most databases, but leave it on Preserve if your database treats them as case-sensitive.
- Why do I get a parse error?
- Either the query has a syntax error, such as an unclosed parenthesis or quote, or it uses syntax the selected dialect does not include. The message shows the line and column where parsing stopped; try the dialect your database actually uses.
- Can I format several statements at once?
- Yes. Separate them with semicolons and each is formatted in turn, with the number of blank lines between them that you choose.
- Are comments kept?
- When formatting, yes: line and block comments stay where they were. Minify removes them, except optimizer hints and MySQL executable comments.
- How do I minify a SQL query to one line?
- Choose Minify at the top of the tool. Comments are removed and whitespace is collapsed, while string literals and quoted identifiers are kept exactly as written.