SQL Formatter
Paste a messy, nested, or single-line SQL query and get clean, indented, readable SQL. Supports multiple dialects and configurable keyword casing so your queries are easy to review and debug.
About the SQL Formatter
SQL queries grow quickly — multiple joins, nested subqueries, long WHERE clauses — and when they arrive as one unbroken line they are nearly impossible to review. A formatter applies consistent indentation, line breaks, and capitalization so the structure of the query becomes visible.
Readable SQL is easier to debug, easier to review in a pull request, and less likely to hide a logic error in a misplaced clause. Because different engines have slightly different syntax, choosing the right dialect ensures keywords and operators are formatted correctly.
Dialect differences are more than cosmetic: SQL Server (T-SQL) uses SELECT TOP 10 where MySQL and PostgreSQL use LIMIT 10; MySQL quotes identifiers with backticks while PostgreSQL and standard SQL use double quotes; BigQuery has its own function set for arrays and structs that doesn't exist in traditional row-oriented databases. Formatting with the right dialect selected keeps these differences intact instead of forcing every query into one generic style.
A consistently formatted query also makes version control far more useful — a one-line SQL diff is nearly unreadable, while a formatted query lets git diff and code review tools show exactly which JOIN or WHERE clause changed. That's why some teams run a SQL formatter as a pre-commit hook or CI check, the same way many run one for JavaScript or Python.
How to use it
- 1Paste your SQL query into the input panel.
- 2Pick your database dialect and preferred keyword case.
- 3Copy the cleanly formatted result for your editor or pull request.
Features
- Formats SQL across MySQL, PostgreSQL, T-SQL, SQLite, BigQuery and more
- Configurable keyword case (UPPER / lower) and indentation
- Handles deeply nested subqueries and long JOINs
- One-click copy of the formatted query
Frequently asked questions
Which SQL dialects are supported?
Standard SQL plus MySQL, PostgreSQL, T-SQL (SQL Server), SQLite, BigQuery, MariaDB and others. Pick the one that matches your database for the best results.
Does it change my query logic?
No. Formatting only changes whitespace and keyword casing for readability — the query itself is unchanged.
Can it format an invalid query?
It formats based on SQL tokens, so it can usually tidy partial or slightly invalid SQL, though severely malformed input may not format cleanly.
Is my SQL sent anywhere?
No. Formatting runs entirely in your browser, so queries containing real table or column names stay private.
Why does dialect matter for formatting?
Different engines use different syntax for the same idea — T-SQL's SELECT TOP vs. MySQL/PostgreSQL's LIMIT, backtick vs. double-quote identifiers, BigQuery's array/struct functions. Picking the matching dialect keeps those details correct instead of normalizing them into the wrong syntax.
Why format SQL before committing it to version control?
An unformatted, single-line query produces an unreadable diff. Consistent formatting means git diff (and PR review tools) shows exactly which clause changed, the same benefit code formatters give for application code.
Does formatting fix bad SQL?
No — it only changes whitespace, line breaks and keyword casing for readability. It won't catch logic errors, and it doesn't validate the query against an actual database schema.