SQL Formatter
Format and beautify SQL for PostgreSQL, MySQL, SQLite and more.
About this tool
Paste a query, even a long one-liner from a log, and get it laid out one clause per line. Choose the SQL dialect, keyword case and indentation.
How to use it
- Paste a query, for example a long one-liner copied from a log or an ORM debug output.
- Choose your database dialect so its keywords and syntax are recognised.
- Pick keyword case (UPPER, lower or as typed) and indentation, or One line to compact it.
- Copy the formatted query.
Questions
- Which databases are supported?
- Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL and Trino/Presto.
- Does formatting change what the query does?
- No. Only whitespace and, if you choose, the case of keywords change. Identifiers, string literals and the query logic stay exactly as they were.
- Can I format several statements at once?
- Yes. Separate them with semicolons and each statement is formatted on its own, with a blank line in between.
- Is my query sent anywhere?
- No. Formatting runs in your browser, so queries with table names or data from production never leave your machine.
- Does the SQL formatter check my query for errors?
- No. It lays out tokens but doesn’t validate the query against a database or a schema, so select a, from t is formatted without complaint. Errors appear only when the text can’t be read in the chosen dialect at all. Run the query, or EXPLAIN it, to find real mistakes.
- Is One line safe for queries with -- comments?
- Not always. A -- comment runs to the end of the line, so once the query is collapsed onto one line, everything after the comment becomes part of it. Remove -- comments or rewrite them as /* … */ before using One line. Block comments are safe on a single line.
- Can I format dbt models or other templated SQL?
- Not directly. Template tags written with double curly braces, along with control blocks like if and for, are not SQL, so the formatter stops with a parse error at the first tag. Compile the model first, for example with dbt compile, and format the generated SQL.
What does a SQL formatter do?
A SQL formatter rewrites a query so its structure is visible. Each clause, such as SELECT, FROM, JOIN, WHERE, GROUP BY and ORDER BY, starts on its own line, the columns and conditions under it are indented, and parentheses open an indented block. A one-liner like select id, email from users where active = true and (plan = 3 or trial = true) becomes a dozen short lines where you can see which conditions belong together.
Keyword case is a matter of convention. UPPER is the traditional style that makes keywords stand out from table and column names, lower is common in newer style guides and analytics teams, and As typed leaves keywords alone when you only want to fix the layout. Choose 2 or 4 spaces of indentation, or One line to compact a query for a code string or a log search. SQL comments are kept in the output.
Why won’t my SQL format? Fixing “Parse error: Unexpected”
The SQL formatter reads the query with the rules of the selected dialect, so syntax from another database causes an error such as “Parse error: Unexpected … at line 1 column 8”. Backtick-quoted identifiers like `order` are MySQL, MariaDB, BigQuery and Spark syntax and fail under PostgreSQL or SQL Server. Square brackets like [order] belong to SQL Server and fail under MySQL. Pick the dialect the query was written for and the error usually disappears.
Placeholders depend on the dialect too. A ? from JDBC or a MySQL driver works in Standard SQL, MySQL, PostgreSQL and SQLite, $1 works in PostgreSQL, and SQL Server expects named parameters like @id, so a ? there stops the formatter. Template tags from dbt or other Jinja-based tools are not SQL at all and cause a parse error at the first tag. Format the compiled query instead.
SQL style best practices for readable queries
Formatting fixes layout, and a few habits make queries easier to review. Write explicit JOIN … ON instead of listing tables with commas in FROM, give tables short meaningful aliases such as u for users and o for orders, and name the columns you need instead of SELECT *. Common table expressions written with WITH … AS split a long query into named steps that read from top to bottom.
Keep one SQL formatting setup per repository: the same dialect, keyword case and indentation, so reformatting a query never adds noise to code review. To compare two versions of a long query, format both here with identical settings, then paste them into Text Diff. Without that step, a moved line break shows up as a difference even though the query itself is the same.
Something not working, or a result looks wrong? Report a problem with this tool