EN
PT
ES
SQL Formatter
Beautify SQL queries with dialect-aware rules. Standard SQL, PostgreSQL, MySQL, BigQuery, T-SQL and SQLite — all in your browser.
What does this tool do?
SQL is a write-once, debug-forever language: you copy a query out of an ORM log or a colleague's chat message and it arrives as a 400-character single-liner. This online SQL formatter takes that wall of text and lays it out on multiple lines with consistent indentation, putting one clause per line, aligning JOIN conditions, and breaking long SELECT lists into vertically stacked columns. It is dialect-aware, so it understands PostgreSQL features like RETURNING, MySQL backticks, T-SQL square brackets, BigQuery EXCEPT column lists, and SQLite quirks — the rendered query stays valid for the engine it was written against. Everything happens in your browser, so the SQL you paste never leaves the tab and never touches a server. The original query is never modified semantically — only whitespace, line breaks and casing change — so you can paste the result back into your codebase, migration file, pull-request description, blog post or chat reply with confidence. Use it to clean up logs from Postgres, MySQL, SQL Server, BigQuery or SQLite, to prepare queries for code reviews, or simply to make a 200-line query readable before you start tuning its execution plan.
How to use it
Pick a dialect that matches the database you are targeting, paste your SQL into the textarea, choose the casing and indentation you prefer, and click Format. The output appears below with a one-click copy button.
- Pick the right dialect — If you are unsure, Standard SQL handles most ANSI-compliant queries. Switch to a vendor dialect when your query uses identifiers like
`backticks`,[brackets], or vendor-only keywords (RETURNING,QUALIFY, etc.). - Choose a casing — UPPER is the de-facto standard for SQL in code reviews. lower reads more like prose. Preserve keeps whatever you already typed.
- Set indentation — 2 spaces is the most common default. 4 spaces is friendlier for nested CTEs. Tab matches editors configured for tab-only indentation.
- Format and copy — Click Format SQL, review the output, and use the copy button to put it on your clipboard. Paste it back into your editor, migration file, or chat reply.
Formatting rules in plain English
The formatter emits one main clause per line: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. Each JOIN sits on its own line with the matching ON condition indented one level. Items in a SELECT list, VALUES tuple or IN (…) clause are split across lines when they exceed the line width. Subqueries and CTEs receive an extra indent level relative to their parent. Comments (-- and /* */) are preserved verbatim. The result is the same set of statements you started with — just laid out so that human reviewers can scan the structure of the query at a glance.
Dialect cheat sheet
Each dialect handles identifier quoting, string concatenation, and a handful of vendor keywords differently. Pick the dialect that matches the engine you are writing for.
| Dialect | Quirks the formatter respects |
|---|---|
| Standard SQL | ANSI-compliant baseline. Double quotes for identifiers, single quotes for strings, || for concatenation. |
| PostgreSQL | Adds RETURNING, ON CONFLICT, ::cast, dollar-quoted strings ($$), and array literals. |
| MySQL | Backtick identifiers, STRAIGHT_JOIN, SQL_CALC_FOUND_ROWS, double-quoted strings allowed. |
| BigQuery | Backtick project/dataset/table refs, EXCEPT in column lists, QUALIFY, UNNEST. |
| T-SQL (SQL Server) | Square-bracket identifiers, TOP n, OUTPUT INSERTED.*, NOLOCK hints. |
| SQLite | Mostly ANSI; minor differences in WITHOUT ROWID, CONFLICT handling, and the lax type system. |
Frequently asked questions
Is my query sent to a server?
No. Formatting happens entirely inside your browser tab, so the SQL you paste — including any sensitive table names, column names, hardcoded ids or production data baked into WHERE clauses — never reaches our servers or any third party. You can disconnect from the network after the page has loaded and the formatter still works.
Why does the result look slightly different from my IDE's formatter?
Every SQL formatter has its own opinions about line breaks, comma-leading vs comma-trailing, and how to wrap long CASE expressions. The defaults here follow conventions that are common across professional database editors and code reviews. If you need an exact match with your team style guide, run the result through your team's preferred formatter as a final pass.
Will it run my query?
No. Only formatting (whitespace and casing) happens. The query is never executed, parsed against a database schema, or sent anywhere.
Does it understand stored procedures and PL/pgSQL blocks?
It formats the outer SQL fine but treats the inner procedural body as opaque text — line breaks inside BEGIN … END are preserved but not rewrapped. For complex stored procedures use a vendor-specific tool such as PGAdmin's formatter.
What if I leave the dialect on Standard SQL but my query uses MySQL backticks?
The formatter will usually still produce a sensible result, but vendor-only keywords may end up unindented or mis-cased. Pick the matching dialect for the cleanest output.
Can it handle multiple statements separated by semicolons?
Yes. Multiple statements separated by ; are formatted independently and joined with a blank line between them. This is handy for pasting in a whole migration script.