🗄️ 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 — leading versus trailing commas, 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 clean, indented, syntax-structured SQL instantly
- Click Copy SQL to copy formatted query to your clipboard
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 — do it as its own commit so 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 are preserved but may move relative to the statements they annotate.
- 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.
Frequently Asked Questions
Which SQL dialects are supported?
Why is SQL query formatting important?
Is my SQL sent to a server?
Does formatting change what the query does?
Does it work with any SQL dialect?
Why does it uppercase keywords?
Can it format a very long query?
Will it fix a syntax error?
References & Further Reading
- PostgreSQL — SQL Syntax: Identifiers and Key Words — Authoritative description of identifier quoting and case folding