SQL formatter
Beautify messy SQL with consistent indentation and keyword casing, across major dialects.
Output will appear here
Why format SQL
SQL is easy to write on one long line and painful to read that way. A query copied from application logs, an ORM or a colleague often arrives as an unbroken string with inconsistent capitalisation and no indentation. Formatting rewrites it with each clause on its own line and nested expressions indented, so the shape of the query — what it selects, where it joins, how it filters — becomes visible immediately. That makes queries easier to review, debug and hand over, and it makes diffs in version control far cleaner.
Formatting never changes what a query does. It only adjusts whitespace and, optionally, keyword casing. The statements you get back are equivalent to the ones you pasted.
Dialects and why they matter
SQL is a family of closely related languages rather than a single one. Each database engine adds its own keywords, functions and syntax on top of the standard. Choosing the dialect that matches your database helps the formatter recognise those engine-specific constructs and lay them out correctly. This tool supports:
- Standard SQL — a good default for portable queries.
- PostgreSQL — Postgres-specific syntax and functions.
- MySQL — including MySQL and MariaDB conventions.
- SQL Server (T-SQL) — Microsoft SQL Server.
- BigQuery — Google BigQuery Standard SQL.
- SQLite — the embedded database used widely on mobile and in apps.
- Oracle (PL/SQL) — Oracle Database.
Keyword casing conventions
A long-standing convention writes SQL keywords (SELECT, FROM, WHERE, JOIN) in uppercase and identifiers (table and column names) in lowercase, so the structural words stand out from your data. The keyword-case control lets you enforce that with a click:
- UPPER — keywords in uppercase, the most common house style.
- lower — keywords in lowercase, preferred by some teams and style guides.
- Preserve — leave casing exactly as you wrote it.
The indentation control (2 spaces, 4 spaces or a tab) sets how deeply nested clauses and sub-queries are indented, so you can match your team's existing style.
Tips for readable SQL
- Format before code review — a consistently laid-out query is far easier for a reviewer to reason about.
- Pick one keyword case and stick to it across your codebase for consistent diffs.
- Use the dialect that matches production, so engine-specific syntax is not mangled.
- Formatting is a safe, mechanical step: since it never changes behaviour, you can apply it freely to queries you do not fully understand yet.
Frequently asked questions
- Which SQL dialects are supported?
- Standard SQL plus PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, SQLite and Oracle (PL/SQL). Pick the one that matches your database so dialect-specific syntax is formatted correctly.
- Does formatting change what my query does?
- No. Formatting only adjusts whitespace and, if you choose, keyword casing. The logic and results of the query are unchanged.
- Is my SQL sent to a server?
- No. Formatting runs entirely in your browser. Nothing you paste is uploaded, so it is safe to format queries that reference sensitive schema or data.
- Why does it show an error instead of formatting?
- The formatter parses your SQL first, so genuinely malformed syntax — unbalanced parentheses, incomplete statements — cannot be laid out and is reported instead. Fix the syntax and format again.
- Can it format multiple statements at once?
- Yes. Paste several statements separated by semicolons and each will be formatted in turn.
- Will it uppercase my table and column names?
- No. The keyword-case option only affects reserved SQL keywords. Your identifiers — table names, column names and aliases — are left exactly as written.