SQL Formatter
Readable, consistently indented SQL for 20 dialects — or a safe one-line copy.
The input has changed since this result was made — format again to update it.
About the SQL Formatter
Paste a query and get it back with one clause per line, consistent indentation and keywords in the case you choose. The formatter knows the syntax of 20 SQL dialects — MySQL, PostgreSQL, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Spark and more — so backtick names, [bracketed] names, $1 parameters and $$ bodies are read correctly.
It can also minify SQL into a compact copy for logs, config files or code strings. Minifying only removes whitespace between tokens: text in quotes, quoted names and comments are copied exactly, and if something cannot be minified safely you get an explanation instead of broken SQL.
How to use it
- Paste SQL into the box, drop a
.sqlfile onto it, or use Open file. - Choose your database under Dialect — it decides how quotes, comments and parameters are read.
- Pick keyword case, indentation and the gap between statements. More options has function and data-type case, AND/OR placement and operator spacing.
- Press Format SQL (Ctrl/⌘ + Enter) or Minify SQL, then copy or download the result.
Examples
select id, name from users where status = 'active' and created_at > '2026-01-01' order by name
SELECT id, name FROM users WHERE status = 'active' AND created_at > '2026-01-01' ORDER BY name
SELECT o.id,
o.total -- before tax
FROM orders o
WHERE o.status = 'paid'
AND o.note <> 'gift wrap';SELECT o.id,o.total FROM orders o WHERE o.status = 'paid' AND o.note <> 'gift wrap';
The double space inside 'gift wrap' is kept, because it is part of the string.
SELECT name FROM users WHERE (id = 1
Line 1, column 37: The SQL ends unexpectedly. Check for an unclosed parenthesis, a trailing comma or an unfinished clause at the end.
Common uses
- Reading long queries copied from application logs, ORMs or BI tools before reviewing or debugging them.
- Giving migrations and reports one consistent style (for example UPPERCASE keywords, 2-space indent) before committing.
- Turning a query into a single line for a code string, an environment variable or a JSON config.
- Spotting unbalanced parentheses and misplaced clauses — errors show the line and column.
Choosing the right dialect
Databases disagree on details that matter to a formatter: how names are quoted ("name" in PostgreSQL, [name] in SQL Server, backticks in MySQL), which characters start a comment (# is a comment in MySQL but an operator in PostgreSQL), and what parameters look like (?, $1, :name, @name). Standard SQL is the strictest choice; if you see a “does not recognise” error, select the dialect your database uses. With Snowflake, stage references such as @mystage/path/, @~ and @%mytable and the file:// paths of PUT and GET are kept exactly as you wrote them.
Supported dialects: BigQuery, ClickHouse, Db2, Db2 for i, DuckDB, Hive, MariaDB, MySQL, Couchbase N1QL, Oracle PL/SQL, PostgreSQL, Redshift, SingleStoreDB, Snowflake, Spark SQL, SQLite, SQL Server (T-SQL), TiDB, Trino/Presto and Standard SQL.
Scripts with GO, DELIMITER and other client commands
Some lines are read by your SQL client, not by the database: GO (SQL Server), DELIMITER (MySQL), / (SQL*Plus, with the Oracle PL/SQL dialect), psql meta-commands such as \connect and sqlite dot-commands such as .mode. They are kept on their own lines and the SQL between them is formatted separately; after DELIMITER $$, each statement keeps its $$ ending. Formatting a whole script at once would join a GO line to the query above it (SELECT 1 GO), turning it into a column alias.
How minifying stays safe
- Only whitespace between tokens changes. Strings, quoted names, comments and
$$bodies are copied character for character. - A space before
(is never removed, because MySQL readsCOUNT (andCOUNT(differently. - A
-- commentkeeps the line break that ends it, and whole-line client commands —GO(SQL Server),DELIMITER(MySQL),/(SQL*Plus) and psql\commands— stay on their own lines. - With Keep comments off, optimizer hints (
/*+ … */) and MySQL and MariaDB executable comments (/*! … */,/*M! … */) are still kept, because they change how a query runs. - As a final check the minified SQL is read again and must contain exactly the same tokens; if not, nothing is changed and you are told why.
Keeping part of a script exactly as written
Wrap a section in /* sql-formatter-disable */ and /* sql-formatter-enable */ comments. Everything between them is copied unchanged by both Format and Minify — useful for hand-aligned INSERT values or syntax the formatter does not understand.
Limitations
- Formatting uses the open-source sql-formatter library, which lays out stored-procedure and trigger bodies (
BEGIN … END) statement by statement, so their indentation is not ideal. The SQL itself is not changed. - It formats SQL; it does not run it or check it against your schema. A query can format cleanly and still fail, for example because of a misspelled column.
- An unquoted name that is also a reserved word in the chosen dialect — such as a column called
keyin MySQL oruserin Standard SQL — is treated as a keyword and gets the keyword case. Quote such names, or choose Keep as typed for keywords. - Very large scripts are processed in a background thread. On slower phones a script of several megabytes can take a few seconds; you can cancel at any time.
Privacy
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
Is my SQL uploaded to a server?
No. Formatting and minifying run in your browser, in a background thread. Nothing you paste or open is sent anywhere, so it is safe for queries that reveal table names or data.
Will formatting change what my query does?
No. Only whitespace, line breaks and the letter case of keywords change (plus function names and data types if you choose), and text inside quotes is never touched. As a final check, the result is compared with your SQL ignoring whitespace and letter case; if anything else differs, you get an error instead of a changed query. Two details: a name that is also a reserved word, such as a column called key, is re-cased like a keyword — this matters only where names are case-sensitive (for example MySQL table names on Linux), so quote such names or choose Keep as typed. And in the MySQL-family dialects the space between names such as COUNT and ( is kept exactly as you typed it, because MySQL reads CREATE TABLE count (i INT) as a table name but count(…) as a function call.
Why does it say the dialect does not recognise part of my query?
Each dialect has its own rules for quotes, comments and parameters. Backtick names, for example, are valid in MySQL but not in PostgreSQL. Choose the dialect of the database you run the query on and format again.
Why does minified SQL still contain line breaks?
A -- comment runs to the end of its line, so removing that line break would comment out the rest of the query. Turn off Keep comments (under More options) to get a single line, or use /* … */ comments.
Can I format several statements at once?
Yes. Separate them with semicolons and choose how many blank lines to leave between them.