SQL Formatter
Format and beautify SQL queries for MySQL, PostgreSQL, Oracle, Snowflake, BigQuery, SQLite and T-SQL. Indent JOINs, subqueries, CTEs and CASE expressions. 100% browser-based — your SQL never leaves your device.
What is a SQL formatter?
A SQL formatter (or SQL beautifier) takes a raw, unformatted SQL query — often the kind you copy out of a log or a monolithic ORM dump — and rewrites it with consistent indentation, line breaks and keyword casing so it becomes readable, reviewable and easy to debug. A good formatter is dialect-aware: it knows that MySQL uses backticks for identifiers while PostgreSQL uses double quotes, that BigQuery accepts QUALIFY while Oracle uses ROWNUM, and that T-SQL has its own quirks like TOP instead of LIMIT.
This online SQL beautifier runs entirely in your browser. Paste your query, pick a dialect, and the formatter splits the statement into its clauses (SELECT, FROM, JOIN, WHERE…), indents subqueries and CASE expressions, and applies your preferred keyword case and comma style. Nothing is uploaded — your queries never leave the page.
How to use the SQL formatter
- Paste your SQL in the left pane. Multiple statements separated by semicolons are supported.
- Pick a dialect matching your database (MySQL, PostgreSQL, Snowflake, etc.). The defaults work for most cases.
- Adjust formatting options: indent size (2, 4 or tab), keyword case (UPPER, lower, preserve) and comma position (trailing or leading).
- Click Format. The result appears in the right pane.
- Copy or download the formatted SQL, or hit Replace input to apply changes back to the input pane.
Supported SQL dialects
The formatter recognises 9 dialects and applies the right identifier quoting, reserved words and clause grammar for each:
| Dialect | Identifier quoting | Notable keywords |
|---|---|---|
| Standard SQL | "double quotes" | ANSI SQL-92/99 subset |
| MySQL / MariaDB | `backticks` | LIMIT, GROUP_CONCAT, REGEXP |
| PostgreSQL | "double quotes" | RETURNING, LATERAL, EXCLUDE, FILTER |
| Oracle PL/SQL | "double quotes" | ROWNUM, CONNECT BY, MERGE, MINUS |
| T-SQL (SQL Server) | [brackets] or "quotes" | TOP, OUTPUT, NOLOCK, CROSS APPLY |
| Snowflake | "double quotes" | QUALIFY, FLATTEN, VARIANT, COPY INTO |
| BigQuery | `backticks` | QUALIFY, UNNEST, STRUCT, ARRAY |
| SQLite | "double quotes" or `backticks` | PRAGMA, ATTACH, WITHOUT ROWID |
| Amazon Redshift | "double quotes" | DISTKEY, SORTKEY, COPY, UNLOAD |
Formatting options explained
Indent
2 spaces is the default in most modern style guides (GitLab, Holistics). 4 spaces is common in legacy enterprise codebases. Tab respects the user's editor settings but breaks on tools that hardcode width.
Keyword case
UPPERCASE is the traditional convention — keywords stand out from identifiers. lowercase is the modern style favoured by many Postgres developers and the Mode style guide. Preserve keeps whatever case you wrote, useful when reformatting code that already has a strict house style.
Comma position
Trailing commas (col1,col2,) is the dominant style — easier to scan top-to-bottom. Leading commas (, col1, col2) — the "elephant style" — makes it harder to omit a column when copy-pasting and is preferred by some teams for that reason.
Common SQL style guides
- GitLab Data Team style guide — lowercase keywords, 2-space indent, leading commas, snake_case identifiers.
- Holistics SQL style guide — uppercase keywords, 2-space indent, trailing commas, each clause on its own line.
- Mode Analytics style guide — lowercase keywords, 2-space indent, trailing commas, CTEs liberally.
- SQLFluff defaults — uppercase keywords, 4-space indent, trailing commas — the most common defaults across linters.
Use cases
- PR / code reviews — uniform formatting eliminates diff noise on whitespace changes.
- Query optimisation — visually scanning a 200-line query for missing JOIN conditions is faster on formatted SQL.
- ETL & dbt models — keep CTEs readable as they grow; SQLFluff and similar tools follow the same rules this formatter applies.
- Logged or generated SQL — clean up the unformatted strings emitted by ORMs (Sequelize, SQLAlchemy, Hibernate) before debugging.
- Learning SQL — a clean structure makes the relationship between SELECT, FROM, JOIN and WHERE clauses obvious.
- Documentation — paste pre-formatted queries into READMEs, runbooks and wikis.
Frequently Asked Questions
No. The formatter is 100% client-side — tokenisation and reformatting run in your browser, your SQL is never uploaded, and the page works offline once loaded. Safe to use with production queries, credentials in comments, or sensitive table names.
Nine dialects: Standard SQL (ANSI), MySQL/MariaDB, PostgreSQL, Oracle PL/SQL, T-SQL (SQL Server), Snowflake, BigQuery, SQLite and Amazon Redshift. The formatter recognises dialect-specific reserved words and identifier quoting (backticks for MySQL/BigQuery, double quotes for Postgres, brackets for T-SQL).
Trailing commas put the comma at the end of the line: col1,col2,. Leading commas put it at the start: , col1, col2. Trailing is the dominant convention because it reads naturally; leading is preferred by some teams because it makes it harder to silently drop a column when commenting lines out or copying.
Yes. Separate statements with semicolons; each one is formatted independently. Enable "Blank lines: Between statements" to add a visual gap between them.
CTEs (WITH clauses) and subqueries are detected and indented. A subquery wrapped in parentheses that starts with SELECT or WITH gets its own indented block. Deeply nested subqueries are correctly indented down to multiple levels.
The formatter only re-cases tokens that match its built-in keyword list (~250 SQL keywords). Identifiers like column or table names — and dialect-specific identifiers the formatter does not recognise — are kept as you wrote them. Use the Preserve case option to disable re-casing entirely.
No, this is a formatter, not a parser or linter. It will happily format invalid SQL — the output will look pretty but still be invalid. For schema-aware validation, run the query against your database or use a dedicated linter like SQLFluff or sql-lint.
Short CASE expressions stay on one line. Multi-branch CASE expressions split each WHEN/THEN onto its own indented line ending in END. If your CASE is heavily nested, the formatter may not split it ideally — manually re-format the inner part if needed.