SQL Formatter
SQL is not one language. Pretty-print without a dialect will “fix” Postgres into MySQL, then you paste it into prod.
SQL is not one language. Pretty-print without a dialect will “fix” Postgres into MySQL, then you paste it into prod.
Pick the dialect first. Then paste. Read the output for the identifier quotes and the limit clause, not for the commas.
How to use it
- Set dialect before format. Postgres uses
"identifiers"andLIMIT. MySQL uses backticks andLIMIT. SQL Server uses[brackets]andTOP/OFFSET FETCH. SQLite is its own mix. LIMIT 10is notTOP 10is notFETCH FIRST 10 ROWS ONLY. A formatter that rewrites that without asking is lying.- Trailing commas in
SELECTlists are not SQL. They're a copy-paste from JS. The error will point at the next keyword, not the comma. - Comments:
--to end of line,/* */block. A#comment is MySQL. Don't ship it to Postgres.
When it breaks
- Reserved words as column names need quoting in that dialect, not in general.
userandorderare the usual victims. - This will not make a bad query fast. It will not bind parameters for you. It will not catch
SELECT *as a problem. - Don't format a migration and assume the dialect you clicked matches the database that will run it.
Input SQL
Loading editor...
Formatted SQL
Loading editor...
Features
- Dialect selector: PostgreSQL, MySQL/MariaDB, SQLite, SQL Server, BigQuery, Snowflake
- Keyword case and indent without running the statement
- Parse errors tied to the selected dialect, not generic SQL
- Preserves string literals, dollar quotes, backticks, and brackets
Common Use Cases
- Pretty-print a Postgres query that MySQL dialect would reject ($$, ILIKE)
- Format a BigQuery script without treating backticks as MySQL errors
- Normalize keyword case before a Git diff in one dialect
- See why a T-SQL [bracket] identifier failed under PostgreSQL
SQL is not one language
SQL is not one language. Pretty-print without a dialect will “fix” Postgres into MySQL, then you paste it into prod.
Pick the dialect first. Then paste. Read the output for the identifier quotes and the limit clause, not for the commas.
Set dialect before format. Postgres uses "identifiers" and LIMIT. MySQL uses backticks and LIMIT. SQL Server uses [brackets] and TOP / OFFSET FETCH. SQLite is its own mix. LIMIT 10 is not TOP 10 is not FETCH FIRST 10 ROWS ONLY. A formatter that rewrites that without asking is lying.
Trailing commas in SELECT lists are not SQL. They're a copy-paste from JS. The error will point at the next keyword, not the comma. Comments: -- to end of line, /* */ block. A # comment is MySQL. Don't ship it to Postgres.
Examples
SELECT $$it's a string$$;SELECT `order` FROM `user`;SELECT * FROM users WHERE name = 'AdaFrequently Asked Questions
SQL is not one language. Pretty-print without a dialect will “fix” Postgres into MySQL, then you paste it into prod. Set dialect before format. Postgres uses "identifiers" and LIMIT. MySQL uses backticks and LIMIT. SQL Server uses [brackets] and TOP / OFFSET FETCH. SQLite is its own mix.
LIMIT 10 is not TOP 10 is not FETCH FIRST 10 ROWS ONLY. A formatter that rewrites that without asking is lying.
Trailing commas in SELECT lists are not SQL. They're a copy-paste from JS. The error will point at the next keyword, not the comma. Comments: -- to end of line, /* */ block. A # comment is MySQL. Don't ship it to Postgres.
Reserved words as column names need quoting in that dialect, not in general. user and order are the usual victims. This will not make a bad query fast. It will not bind parameters for you. It will not catch SELECT * as a problem. Don't format a migration and assume the dialect you clicked matches the database that will run it.
Common Mistakes
Tips
- 2-space indent for diffs; 4-space if the team already uses it.
- If the error mentions the default sql dialect, pick PostgreSQL or MySQL instead.
- Dollar-quoted bodies need PostgreSQL. Backticks need MySQL or BigQuery.