What SQL Formatter helps you do

Long single-line queries are hard to review and easy to misread in a pull request. This formatter applies dialect-aware rules to split clauses, indent subqueries, and normalize keyword casing, while leaving identifiers and literals untouched. It is a readability pass for pasted queries, not a validator for business logic.

Formatting runs in your browser, and the query never leaves your device. That matters because real queries often contain table names, column names, and literal values.

How it works

The query is parsed with the rules for the selected dialect, then printed with consistent clause breaks, indentation and keyword casing. Comments are attached to the tokens they precede. If the parser cannot understand the syntax, it reports the position instead of emitting a half-formatted query.

How to use SQL Formatter

Paste a query, or select Load example to see the result on a sample.
Pick the dialect that matches your database, plus keyword casing and indentation.
Select Format SQL and review the output against the original.
Copy the result or download it as a .sql file.

When to use it

Cleaning up a pasted query before adding it to a migration or code review.
Making a generated or ORM-produced query readable while debugging.
Standardizing keyword casing across a team's SQL snippets.
Explaining a complex join or subquery in a support ticket.
Preparing a query for documentation or a runbook.
Spotting missing clauses by making the structure visible.

When not to use it

Do not use it to validate business logic or permissions.
Do not expect a MySQL-specific query to parse under PostgreSQL rules.
Do not use it to minify or execute a query.

Example

A 900-character query from an ORM is pasted with the PostgreSQL dialect. The formatter puts SELECT, FROM, JOIN, WHERE and GROUP BY on separate lines, leaves the identifiers and date literal untouched, and keeps the two comments attached to their clauses. The review finds a missing join condition that was invisible on one line.

What you can do with SQL Formatter

Format Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite and T-SQL.
Format BigQuery, Snowflake and Oracle PL/SQL with their dialect rules.
Choose keyword casing and indentation.
Keep line and block comments attached to their statements.
Report a parser error with its position for invalid SQL.
Copy the result or download it as a .sql file.
Choose the indentation width.
Format a single statement at a time.

Example: clean up an ORM query

Paste the generated query and choose the database dialect. A query produced for MySQL may use backticks or syntax that PostgreSQL does not accept.

Format it and compare the clauses with the original. The formatter only changes whitespace and keyword case, so the structure should be identical and the intent easier to review.

Paste the formatted query into the migration or pull request, and run it in a development database before merging.

What to know before you start

The formatter changes whitespace and keyword casing only; it does not validate business logic.
Dialect choice matters: a query written for MySQL may not parse under PostgreSQL rules.
Invalid SQL returns a parser error instead of partial output.
This tool beautifies; it does not minify or execute queries.
Procedural blocks and vendor-specific extensions may not be fully supported.

Common mistakes

Choosing the wrong dialect and getting a parser error.
Assuming formatting fixes a missing clause or a bad join.
Pasting a query that mixes statements from two dialects.
Expecting comments to move with a clause after a manual edit.
Treating the formatted output as tested; it still needs to run.

Troubleshooting

If formatting fails, check the dialect first. Backticks, bracket identifiers and LIMIT/OFFSET syntax vary between engines.

If the output loses a comment, confirm that the comment is inside the pasted text and not above it.

If a stored procedure fails, PL/SQL and T-SQL procedural blocks may need a simpler statement or the database's own formatter.

If the query is very long, format one statement at a time to keep the error position useful.

If the output looks unchanged, the query may already be formatted or the formatter is not applying the chosen options.

If an identifier contains a keyword, the formatter may change its case in some dialects. Quote the identifier or check the output before committing, especially for columns named order or group.

If the output is very wide, lower the indent width or format one statement at a time.

SQL Formatter