SQL Formatter — Beautify a Query in Your Own Dialect
Paste a query that arrived as one long line and get it back properly indented, with the keywords cased the way your team writes them. Pick your actual dialect — PostgreSQL, MySQL, T-SQL, BigQuery, Snowflake, Oracle, DuckDB and a dozen more — so dialect-specific syntax is understood instead of being mangled. Nothing is sent anywhere; the query is formatted in the tab.
That last point is the reason this page exists. Most SQL beautifiers on the web post your query to a server, and a query is rarely just syntax: it carries table names, column names, hard-coded IDs, email addresses in a WHERE clause, sometimes a schema you would rather not publish. Pasting production SQL into an unknown endpoint is a habit worth breaking, and formatting is a job a browser can do on its own.
Why the dialect matters
SQL is a family, not a language. T-SQL uses square-bracket identifiers and TOP; MySQL uses backticks and LIMIT; BigQuery has array and struct syntax that nothing else does; Oracle has its own date handling. A formatter told the wrong dialect will either leave those constructs alone or break them across lines in ways that read badly. Choosing correctly costs one click and makes the difference between output you keep and output you re-edit.
A house style, applied consistently
Uppercase keywords against lowercase identifiers is the most widely used convention, because it makes the shape of a statement readable at a glance — you can find the FROM in a forty-line query without reading it. Two-space indentation keeps deeply nested subqueries on screen; four is easier to scan in a short query. There is no correct answer, only a consistent one, and a formatter is how a team stops arguing about it in review.
What formatting will not do
Reindenting changes nothing about how a query runs. It will not make a sequential scan into an index seek, it will not rewrite a correlated subquery as a join, and it will not tell you that your LEFT JOIN has been quietly turned into an inner join by a condition in the WHERE clause. It also cannot validate against your schema — a perfectly formatted query can still reference a column that does not exist. Use EXPLAIN in your own database for the questions that matter to performance.
Related: format other languages with the code beautifier, compare two versions in the diff checker, or reshape a result set with CSV to JSON.
How to use SQL Formatter
- Choose the dialect you are actually writing against — the default Standard SQL is a safe fallback, but a real dialect handles its own syntax better.
- Paste the query, or load the example to see the formatting before you commit anything of your own.
- Set keyword case and indent width. Uppercase keywords with two-space indents is the most common house style.
- Read the formatted output. If the parser reports an error it names the token it stopped on, which is usually the real problem in the query.
- Copy it, download it as a .sql file, or press Minify to collapse it back to a single line for a config or a log.
Features
- Sixteen dialects — PostgreSQL, MySQL, MariaDB, T-SQL, Oracle PL/SQL, SQLite, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark, Hive, Trino and more.
- Keyword case control — upper, lower, or leave exactly as written.
- Two spaces, four spaces or tabs — match whatever your repository already uses.
- Minify as well as beautify — collapse a formatted query back to one line when you need it in a string or a config file.
- Real parse errors — the message names the token that failed rather than a generic failure.
- The query never leaves your browser — table names, IDs and hard-coded values stay on your machine.
Frequently Asked Questions
Is my SQL sent to a server?
No. The formatter runs as JavaScript in this tab. That matters more than it sounds: queries routinely contain schema names, customer IDs and email addresses, and pasting them into a remote service quietly discloses all of it.
Which dialect should I choose?
The one your database actually speaks. Standard SQL works for ordinary SELECT statements, but square-bracket identifiers need T-SQL, backticks need MySQL or MariaDB, and array or struct syntax needs BigQuery. Picking the right one avoids odd line breaks around dialect-specific syntax.
Does formatting change what the query does?
No. Only whitespace and keyword capitalisation change. SQL keywords are case-insensitive, so uppercasing them is cosmetic; string literals and quoted identifiers are left exactly as written.
Why does it report an error on a query that runs fine?
The parser has to understand a statement before it can lay it out, and very new or vendor-specific syntax occasionally sits outside what it knows. Try the closest matching dialect, or Standard SQL. If it still fails, the statement will run in your database but cannot be reformatted here.
Can it uppercase keywords but leave my column names alone?
Yes — that is exactly what the keyword case setting does. Identifiers, string literals and comments are untouched, so only the reserved words change.
Will it make my query faster?
No. Formatting is presentation only. Query performance comes from indexes, join order, statistics and the plan your database chooses — run EXPLAIN against the real database to see any of that.
Can I format several statements at once?
Yes. Paste a whole script separated by semicolons and each statement is formatted in turn, which is the usual way to tidy a migration file.