Format SQL queries so they are easy to read
The SQL Formatter turns long, single-line or inconsistently written SQL into clean, indented queries with each clause — SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY — on its own line. It understands the syntax of 13 SQL dialects, including MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, Oracle PL/SQL, BigQuery, Snowflake and Amazon Redshift, so dialect-specific features such as backtick identifiers, dollar-quoted strings or square-bracket names are handled correctly.
Use it to tidy a query copied from an ORM log, review a colleague’s migration, prepare SQL for documentation or a code review, or make a slow query readable before you start tuning it. A Minify mode does the opposite: it squeezes a query onto one line and strips comments, ready to paste into code or a config file.
Formatting happens in your browser using the open-source sql-formatter library. Your queries — and any table names, customer data or credentials inside them — are never sent anywhere.
How to use the SQL Formatter
- Paste one or more statements into the SQL query box, drop a .sql file onto it, or press Load file.
- Choose your SQL dialect so the formatter recognises its quoting rules and keywords.
- Set Keyword case, Indent, Blank lines between queries, the Layout and where AND / OR should go.
- Press Format SQL. After that, the output follows your edits automatically. Switch to Minify to get a single-line version instead.
- Copy the result or download it as a .sql file.
SQL Formatter features
13 SQL dialects
Standard SQL, MySQL, MariaDB, PostgreSQL, SQL Server, SQLite, Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino and Db2.
Keyword case control
Uppercase, lowercase or leave keywords as typed — optionally applying the same case to function names and data types.
Three layouts
Standard indentation, or tabular layouts that line clause keywords up in a column on the left or right.
Safe minify mode
Collapses a query to one line without touching strings or quoted identifiers, and keeps MySQL /*! … */ code and /*+ … */ optimiser hints.
Multiple statements
Format whole scripts; statements stay separated by semicolons with your choice of blank lines between them.
Clear parse errors
If the formatter cannot understand a query, it tells you the line and column so you can fix a typo or pick the right dialect.
Before and after
A query like select id, name from users where active = 1 order by name; becomes the layout most SQL style guides recommend: clause keywords at the left margin, each selected column on its own line, and conditions indented beneath the clause they belong to.
Long WHERE clauses benefit most. With “AND / OR position” set to start of line, every condition begins with its logical operator, which makes it easy to comment one out while debugging or to spot a missing bracket between AND and OR.
| Setting | Effect |
|---|---|
| Keyword case: UPPERCASE | select → SELECT, left join → LEFT JOIN |
| Blank lines between queries: 1 | One empty line after each semicolon |
| Layout: Tabular, keywords left | Keywords padded to a fixed width so the column names line up |
| Dense operators | a = b → a=b, saving space in long expressions |
| Semicolon on its own line | Moves the closing ; to a new line, a style some teams prefer for easy appending |
Why the dialect matters
SQL looks similar everywhere, but each database has its own quoting and syntax rules. Choosing the right dialect prevents surprises:
- MySQL and MariaDB quote identifiers with backticks (
`order`), allow backslash escapes inside strings and treat#as a comment. - PostgreSQL uses dollar-quoted strings (
$$ … $$) for function bodies, the::cast operator and nested block comments. - SQL Server quotes names with square brackets (
[Order Date]) and usesTOPinstead ofLIMIT. - BigQuery supports backtick table paths such as
`project.dataset.table`and triple-quoted strings. - Oracle PL/SQL has its own procedural blocks and the
q'[…]'quoting style.
Tips for readable SQL
- Give every table an alias and use it on every column (
o.total_amount), so readers never have to guess where a column comes from. - Prefer explicit
INNER JOIN … ONto listing tables separated by commas in FROM. - Put each selected column on its own line — formatting does this for you — so diffs in version control show exactly which column changed.
- Keep formatted SQL in your repository and minify only where a single line is genuinely needed. For other code, the Code Beautifier handles HTML, CSS, JavaScript and JSON, and the JSON Formatter is ideal for query results exported as JSON.
SQL Formatter FAQ
Is this SQL formatter free and private?
Yes. It is free with no account or limits, and your SQL is formatted locally in your browser. Nothing is uploaded, which matters when queries contain real table names or data.
Which databases does the SQL formatter support?
Standard SQL plus MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), SQLite, Oracle PL/SQL, Google BigQuery, Snowflake, Amazon Redshift, Spark SQL, Trino/Presto and IBM Db2.
Does formatting change what my query does?
No. Only whitespace, line breaks and — if you choose — the letter case of keywords change. Strings, quoted identifiers and comments are kept exactly. Keyword case never matters to SQL databases.
Why do I get a parse error?
The formatter has to understand the query structure. Errors usually mean a typo, an unbalanced bracket or syntax from a different database. Check the line and column shown, and make sure the right SQL dialect is selected.
Can it format stored procedures and multiple statements?
Yes. Paste a whole script and every statement is formatted, separated by blank lines. Very complex procedural code may format less neatly than plain queries, but its meaning is unchanged.
What does Minify SQL do?
It removes comments and line breaks and collapses spacing so the query fits on one line. Text inside quotes is never changed, and MySQL /*! … */ comments and /*+ … */ optimiser hints are kept because they affect how the query runs.