SQL Formatter
Pretty-print SQL queries for PostgreSQL, MySQL, SQLite, MS SQL, and more
How to SQL Formatter Online
Pretty-print SQL queries in any major dialect, with configurable indent and keyword case.
- Pick your SQL dialect from the dropdown. Use Standard SQL if you are not sure or your query is dialect-agnostic.
- Choose indent width (2 spaces is the modern default) and keyword case (UPPER, lower, or preserve as-typed).
- Paste your query into the input textarea. Multi-statement queries (separated by `;`) are supported.
- Click Format. The formatter parses, re-indents on the standard SQL style (each select column on its own line, joins aligned), and produces the cleaned-up version.
- If the formatter cannot parse your query, the error message includes the position. Trim the offending section or switch dialect.
- Click Copy to put the formatted SQL on your clipboard.
About SQL Formatter
Hand-written SQL drifts toward illegibility fast. A correlated subquery with three joins and a window function fits on a screen if formatted well and runs off the bottom otherwise. The standard SQL pretty-printing style — `SELECT` keywords aligned at column zero, the select list one column per line, each join on its own line — exists because it makes diffs in code review readable and turns 80-line queries into something you can scan in seconds. Most database vendors' own documentation uses this style. Most ORM-generated migration files do too. A SQL formatter is the cheapest tool you can hand a backend team to improve code review quality.
This tool wraps the **`sql-formatter`** library, which supports 14 dialects (Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, T-SQL for SQL Server, PL/SQL for Oracle, BigQuery, Redshift, Snowflake, Spark SQL, DB2, Hive, Trino). The reason dialect matters: each engine has its own keyword list (`LIMIT` vs `TOP` vs `FETCH FIRST`), its own string-concatenation operator (`||` vs `CONCAT` vs `+`), its own quoting (`"col"` vs ``col`` vs `[col]`), and its own built-in functions. Pointing the formatter at the right dialect means it understands those constructs and reformats them in their idiomatic style instead of treating them as parse errors.
The three knobs you can tune are **indent width**, **keyword case**, and the dialect. Indent width of 2 spaces matches the dominant modern style guide; 4 spaces matches the historical Microsoft/Oracle convention. Keyword case is a religious war — uppercase keywords (`SELECT`, `FROM`, `WHERE`) are the strict ANSI tradition and remain dominant in DBA and analyst circles; lowercase is more common in modern application code where SQL is embedded in code that follows the language's case conventions (Python, JavaScript). The `preserve` option leaves your keywords as you typed them, which is the right pick when you are running the formatter as part of an editor save action and do not want to fight the developer's choice.
A common confusion worth flagging: **the formatter is not a query rewriter.** It does not move conditions out of joins, does not rewrite `IN` to `EXISTS`, does not optimize anything. It changes whitespace and keyword case only. The actual tokens, identifiers, and execution plan are unchanged. This means your formatted query will execute identically to the original — same plan, same row count, same performance. The win is in human readability, not engine behavior.
For dialect-specific features the parser does not recognize, the formatter returns a clear error pointing at the offending position. The fix is either to switch to Standard SQL mode (which has the loosest parser), trim the unparseable section, or skip the formatter for that query and re-indent by hand. The error never changes your query — it just reports that the formatter cannot handle that exact construct yet. Vendor extensions like Postgres' `LATERAL` joins and BigQuery's array unnesting are widely supported; the unsupported set is mostly the very newest syntax shipped within the last year.
All formatting runs in your browser using the `sql-formatter` library (~50 KB compressed). No network requests, no logging, no server-side parsing — your queries never leave your tab. This matters because SQL queries often contain table names, column names, and schema information that you might not want to send through a third-party site. Paste with confidence; the only thing watching the formatter is your CPU.
Related Tools
Frequently Asked Questions
Which SQL dialect should I pick?
Pick the one your target database actually runs. Dialects differ in keywords, identifier quoting, string concatenation, and built-in functions. Postgres uses `||` for concatenation, MySQL uses `CONCAT()` (and `||` only in ANSI mode), SQL Server uses `+`. Picking the wrong dialect usually produces readable output anyway, but the formatter will not understand dialect-specific syntax (Postgres window-function clauses, BigQuery struct literals, T-SQL `TOP`) unless you select the right one.
Why is my query rejected with a parse error?
The formatter uses `sql-formatter`, which has its own lightweight parser. If your query uses a feature the parser does not recognize — vendor extensions, brand-new syntax, or non-standard custom functions — it may emit a parse error. The fix is to verify the SQL runs in your database, then either trim the unparseable section out, switch to `Standard SQL` mode, or accept that the formatter cannot handle that specific construct. The formatter never modifies your query semantically — it either pretty-prints it or fails cleanly.
Is the formatter safe to use on queries with secrets?
Yes. The whole thing runs in your browser tab. Your queries do not leave your device, are not logged, and never touch a server. You can confirm in your browser's DevTools network panel — formatting produces zero requests. That said: do not paste queries containing literal passwords or API keys into ANY tool you do not control. The right pattern is to parameterize secrets out of the query body entirely.
Does the formatter change query behavior?
No. It re-indents, re-cases keywords, and adjusts line breaks — that is it. The actual tokens, identifiers, literals, and operators are preserved exactly. Comments are preserved. The only thing that can change is whitespace inside string literals if you have multi-line strings, which is one reason to enable the `preserve` keyword-case option when you have unusual content.
Why does the formatter put each column on its own line?
Convention — the dominant SQL style guide (the one used by every major database vendor's documentation) puts each select-list column on its own line when there are multiple columns. This makes long SELECT lists diff cleanly in code review and easier to scan. If you prefer compact output, the `sql-formatter` library does not currently have a 'wrap if shorter than N' mode; the alternative is to keep the input compact and not run it through this formatter.
What is the right indent width?
Two spaces is the most common in modern style guides (Django, Rails, Prisma migrations, most ORM-generated SQL). Four spaces matches the historical Microsoft and Oracle convention. Eight is uncommon today but matches the original tab convention. Use whatever your team's existing SQL files use; if there is no convention, two is the safe default.