SQL Formatter & Beautifier
Format SQL for readable diffs and code review, with an identifier-quoting table for PostgreSQL, MySQL, T-SQL, Oracle and Spark SQL. Runs in your browser.
Clean Formatted SQL
SELECT u.id, u.username, COUNT(o.id) AS total_orders, SUM(o.amount) AS revenue FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.created_at >= "2024-01-01" GROUP BY u.id, u.username HAVING COUNT(o.id) > 5 ORDER BY revenue DESC LIMIT 20;
What SQL Formatter & Beautifier Does
Formatting SQL is about making a query reviewable. A single-line query of two hundred characters is not wrong, but nobody can check the join conditions in it, and a diff of two such lines tells you nothing about what changed.
The conventions that matter are consistent keyword case, one clause per line, and indentation that makes the join and filter structure visible. Beyond that, most formatting arguments, such as leading versus trailing commas or how far to indent, are team preferences rather than correctness questions.
What is not preference is dialect. SQL is standardized loosely and implemented differently, and the way each database quotes identifiers is the difference that most often breaks a query moved between systems.
How to Use SQL Formatter & Beautifier
- Paste your raw unformatted SQL query into the input editor
- Toggle uppercase keywords on or off as preferred
- View the SQL cleanly indented and structured by syntax
- Click Copy SQL to copy formatted query to your clipboard
How SQL Formatter & Beautifier Works
How a query is reformatted
set aside strings, quoted identifiers and comments → normalize ", " spacing → uppercase keywords (optional) → new line before each major clause → new indented line before AND, OR, ON → put the set-aside text back
- set aside
- '…' strings (with '' escapes), "…", `…` and […] identifiers, -- line comments and /* */ block comments are swapped for placeholders first, so nothing inside them is changed.
- major clauses
- SELECT, FROM, WHERE, every JOIN form (LEFT, RIGHT, FULL, INNER, OUTER, CROSS), GROUP BY, HAVING, ORDER BY, LIMIT, SET and VALUES each start a new line.
- subclauses
- AND, OR and ON start a new line indented two spaces.
Worked example
select name, 'a, b or c' as note from t where x = 'it''s on' and y in (1,2) order by name
- The two string literals, 'a, b or c' and 'it''s on', are set aside untouched
- Keywords are uppercased: SELECT, AS, FROM, WHERE, AND, IN, ORDER BY
- FROM, WHERE and ORDER BY start new lines; AND starts an indented line
- (1,2) becomes (1, 2) by the comma rule; the comma inside the string is not touched
Result: SELECT name, 'a, b or c' AS note / FROM t / WHERE x = 'it''s on' / AND y IN (1, 2) / ORDER BY name
Identifier Quoting by Dialect
The single most common portability failure. A query formatted for one database can be syntactically invalid in another purely because of these.
| Database | Identifier quote | String literal | Example |
|---|---|---|---|
| ANSI SQL standard | Double quotes | Single quotes | "my table" |
| PostgreSQL | Double quotes | Single quotes | "my table" |
| MySQL / MariaDB | Backticks (or double quotes in ANSI mode) | Single or double quotes | `my table` |
| SQL Server / T-SQL | Square brackets | Single quotes | [my table] |
| Oracle | Double quotes, case-sensitive | Single quotes | "MY_TABLE" |
| SQLite | Any of the above | Single quotes | Accepts all three |
| Spark SQL | Backticks | Single quotes | `my table` |
Formatting Conventions and Why They Exist
| Convention | Argument for | Argument against |
|---|---|---|
| Uppercase keywords | Separates language from your schema at a glance | Some teams find it shouty; consistency matters more than which |
| One column per line | Adding a column is a one-line diff | Long SELECT lists become tall |
| Leading commas | Commenting out the last column does not break syntax | Unfamiliar to many readers |
| Right-aligned keywords ("river") | Clause boundaries line up visually | Painful to maintain by hand |
| Explicit JOIN syntax | Join conditions are separate from filters | More verbose than comma joins |
What Formatting Cannot Fix
A beautifully formatted query can still be wrong or slow. These are the things reviewers should look for after the formatting is settled.
| Issue | Why it matters |
|---|---|
| SELECT * | Breaks when columns are added; transfers data nobody reads |
| Implicit comma joins | A missing WHERE clause becomes a cross join, silently |
| Functions on indexed columns in WHERE | Prevents the index being used |
| Correlated subqueries in SELECT | Executes once per row; often rewritable as a JOIN |
| String concatenation into SQL | This is SQL injection — use parameterized queries |
| Missing explicit ORDER BY | Row order is not guaranteed without one, whatever you observe in testing |
How to Read Your Result
Formatting is a code-review tool
The practical value is in diffs. With one column per line and a consistent layout, a change to a query produces a one-line diff that a reviewer can actually check. With everything on one line, every edit rewrites the line and the reviewer has to re-read the whole query to find what moved.
Agree a style and automate it
The specific choices matter far less than applying them without argument. Put a formatter in the pre-commit hook or the CI pipeline. Reformatting an existing codebase produces one large diff, so do it as its own commit where it does not obscure real changes.
Uppercase keywords are convention, not syntax
SQL keywords are case-insensitive in every mainstream database; SELECT, select and SeLeCt all work. Uppercasing them is purely so a reader can separate the language from the identifiers. Identifiers themselves may be case-sensitive depending on the database and how they were quoted: Oracle folds unquoted names to uppercase, PostgreSQL folds to lowercase.
Limitations & Accuracy Notes
- This formatter adjusts whitespace, line breaks and keyword case. It does not parse your query semantically, validate it against a schema, or check that it runs.
- Dialect-specific syntax (T-SQL variables and hints, PostgreSQL dollar-quoted blocks, MySQL backticks, procedural blocks) may not format cleanly, and stored procedure bodies are usually best left alone.
- Comments, string literals and quoted identifiers are copied through verbatim and never rewritten, but the line breaks around a comment can change.
- Formatting never changes execution: the query planner ignores whitespace entirely. A slow query formatted beautifully is exactly as slow.
- Queries can contain table names, column names and sometimes literal data. Everything here runs in your browser and nothing is transmitted, but treat production queries with the same care as any other sensitive text.
- Line breaks come from pattern rules, not a full SQL parser. AND inside BETWEEN x AND y, or keywords inside a subquery, get the same line break as a top-level clause.
Frequently Asked Questions
Which SQL dialects are supported?
The formatter supports standard SQL, MySQL, PostgreSQL, SQLite, Microsoft SQL Server, and Oracle syntax.
Why is SQL query formatting important?
Clean, properly indented SQL with uppercase keywords drastically improves query readability, makes code reviews faster, and simplifies debugging.
Does formatting change what a SQL query does?
No. Formatting only affects whitespace, indentation, and keyword casing for readability. The query’s logic, execution order, and results are completely unchanged.
Why do dialects like MySQL and PostgreSQL format slightly differently?
Each database has its own extensions and quoting conventions, such as backticks versus double quotes for identifiers, so dialect-aware formatting avoids syntax that dialect would not accept.
Is my SQL sent to a server?
No. Formatting runs in your browser, which matters because queries routinely contain table names, column names and literal values from a production schema.
Does formatting change what the query does?
No. Only whitespace, line breaks and keyword casing change. The parsed statement is identical, so the result and the execution plan are unaffected.
Does it work with any SQL dialect?
It handles standard SQL well. Dialect-specific extensions, such as PostgreSQL's dollar-quoted function bodies, T-SQL's square-bracket identifiers and MySQL backticks, vary in how cleanly they format, since each database extends the grammar differently.
Why does it uppercase keywords?
Uppercase keywords against lowercase identifiers is the long-standing convention, and it makes the shape of a query scannable at a glance. It is purely cosmetic: SQL keywords are case-insensitive, though in some databases identifiers are not.
Can it format a very long query?
Yes, and that is where it earns its keep. A deeply nested query with several CTEs and joins is where consistent indentation is the difference between readable and unreadable. The limit is browser memory rather than any imposed cap.
Will it fix a syntax error?
No. It formats what you give it. Malformed SQL may format oddly, which is occasionally a useful hint about where the structure breaks, but a formatter is not a validator.
References & Further Reading
- PostgreSQL — SQL Syntax: Identifiers and Key Words — Authoritative description of identifier quoting and case folding