Format and beautify SQL
Paste a query that arrived as one long line and get it back indented, with keywords aligned and clauses on their own lines. Choose the dialect so that engine-specific syntax is parsed correctly, set keyword case and indentation, and keep your data private — formatting happens entirely in the browser.
How to use the SQL Formatter
- Paste the SQL — one statement or a whole script.
- Choose the dialect so engine-specific syntax parses correctly.
- Set keyword case and indentation to match your team style.
- Copy the formatted query back into your editor or migration file.
What formatting changes, and what it does not
Only whitespace, line breaks and the case of reserved words are altered. String literals, quoted identifiers, numbers and comments are preserved exactly as written, so the formatted query is semantically identical to the one you pasted and can be run without re-checking. That is worth knowing before you paste a migration into it: nothing is rewritten, reordered or optimised.
Dialects matter
SQL is a family, not a language. :: casting and ILIKE are PostgreSQL; backtick-quoted identifiers are MySQL; TOP, square brackets and GO batches are T-SQL; QUALIFY belongs to Snowflake and BigQuery; array and struct access differ everywhere. Choosing the right dialect lets the parser recognise these instead of treating them as unknown tokens, which is what produces odd line breaks in a generic formatter. If a query will not parse, switching to Standard SQL usually gets you a usable result.
Reading a formatted query
The standard layout puts each major clause — SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY — at the left margin with its contents indented beneath, and gives every selected column and every join condition its own line. Placing AND and OR at the start of the next line, the default here, makes the logical structure scannable and keeps diffs small when a condition is added. The tabular layouts align keywords in a column instead, a style common in Oracle and reporting shops.
| Setting | Good for |
|---|---|
| Uppercase keywords | The dominant convention; separates language from identifiers at a glance |
| Lowercase keywords | Modern analytics teams, dbt projects |
| Expression width 50 | Side-by-side review in a code review tool |
| Expression width 100+ | Fewer, longer lines on a wide monitor |
Practical uses
Making sense of a query pulled out of an ORM log or an application error, reviewing a colleague's 200-line report query, normalising formatting before committing a migration so the diff shows the real change, and teaching — a well-laid-out query makes the join graph and the filter logic visible in a way that a single wrapped line never does.
Privacy
Queries routinely contain table names, column names and literal values that reveal a great deal about a business, and sometimes personal data in a WHERE clause. This formatter runs in your browser with no network request, so nothing is transmitted or stored.
Frequently asked questions
Does formatting change what my query does?
No. Only whitespace, line breaks and keyword case change. Literals, identifiers and comments are preserved exactly.
What if my dialect is not listed?
Use Standard SQL. It parses the common core and handles most vendor syntax well enough to produce a readable result.
Can it format several statements at once?
Yes. Semicolon-separated statements are each formatted and separated by a blank line.
Is my SQL sent to a server?
No. Parsing and formatting happen entirely in your browser, which matters because queries often contain sensitive table and column names.
Privacy
This tool runs entirely inside your browser using WebAssembly and the Canvas/File APIs. Your files are never uploaded to ToolFlint or any third party; you can verify this in your browser's network tab or by switching to airplane mode after the page loads. Read how we process files.
Last updated 2026-09-23.