SQL Formatter
Paste a SQL query to indent and lay it out consistently, across several common database dialects. Runs entirely in your browser.
Why dialect matters
Standard SQL and its various dialects (MySQL, PostgreSQL, T-SQL, PL/SQL, and others) differ in small but real ways — quoting rules, specific keywords, and syntax extensions like T-SQL's TOP or PostgreSQL's LIMIT/OFFSET. Picking the right dialect helps the formatter recognize these correctly rather than misreading them as errors or formatting them oddly.
What this does and doesn't do
This tool reformats whitespace, indentation, and line breaks to make a query easier to read — it doesn't validate that the query is logically correct, check that tables or columns exist, or optimize the query in any way.
A worked example
Pasting the one-line query below with Standard SQL and uppercase keywords:
select id,name from users where active=1 and created_at>'2026-01-01' order by name
gives:
SELECT id, name FROM users WHERE active = 1 AND created_at > '2026-01-01' ORDER BY name
Choosing lowercase gives the same layout with select, from, where, and and order by in lowercase, and Preserve leaves each keyword as you typed it. Only keywords change; table and column names stay as written. Indentation is fixed at two spaces and cannot be adjusted.
The dialect changes what is accepted
Square-bracket names such as [first name] are valid in SQL Server, and under T-SQL the query select [first name] from [dbo].[t] formats normally. Under Standard SQL the same text stops with a parse error at the first bracket. PostgreSQL casts like x::int and LIMIT 10 OFFSET 5 format cleanly with the PostgreSQL option, and MySQL's LIMIT 5, 10 is kept as written. If a valid query is rejected, try the dialect it was written for.
Errors, comments and multiple statements
- Unbalanced parentheses or an unterminated quote produce a parse error that names the line and column. The formatter needs well-formed text to lay it out.
- Comments are kept, including a trailing -- comment on a line.
- Several statements separated by semicolons are formatted together, each starting after a blank line.
- The tool only changes layout. It does not check names, run the query or optimize it.
Frequently asked questions
Which SQL dialect should I pick?
Pick the database you're actually writing the query for — MySQL, PostgreSQL, SQL Server, PL/SQL (Oracle), SQLite, BigQuery, or Snowflake. If you're not sure or your query uses only common syntax, Standard SQL usually works fine.
Does this validate that my query is correct?
No — it only reformats whitespace and indentation. It doesn't check that tables or columns exist, or that the query's logic is correct.
Is my query sent anywhere?
No — formatting runs entirely in your browser using JavaScript. The query is never sent to a server.
Why do I get a parse error on a query that works in my database?
Usually because the dialect doesn't match. Syntax such as SQL Server's square-bracket names or PostgreSQL's :: casts is only recognized in its own dialect, so pick the one the query was written for. An unbalanced bracket or unterminated string also stops formatting.
Does it keep my comments?
Yes, line comments stay with the code they follow. Only the whitespace and line breaks around them are changed.
Can I format several statements at once?
Yes. Statements separated by semicolons are formatted in one pass, with a blank line between them.