SQL Formatter

How to use

Paste a SQL statement on the left, and the right pane shows it re-indented with one clause per line, joins aligned, and lists broken across lines for readability. Pick the dialect to match your target database (PostgreSQL, MySQL, Snowflake, T-SQL, BigQuery, SQLite, and 8 more) — dialect choice affects how reserved words, quoted identifiers, and dialect-specific clauses (`QUALIFY`, `RETURNING`, `EXCEPT`) are recognized. Keyword case can be set to UPPER (SQL community default), lower, or preserve, and tab width adjusts indent depth between 1 and 8 spaces.

The formatter parses the statement into a clause tree before re-emitting — it is not a regex-based pretty-printer, so a comma split across joins or an inline CASE expression comes out structured rather than just wrapped. It does *not* validate the query against a schema and does *not* execute it. Everything runs in the browser through the `sql-formatter` library, so queries containing internal table names or production data stay on your machine.

Examples

select id, name, email from users where created_at > '2024-01-01' and status in ('active','pending') order by created_at desc limit 100

SELECT
  id,
  name,
  email
FROM
  users
WHERE
  created_at > '2024-01-01'
  AND status IN ('active', 'pending')
ORDER BY
  created_at DESC
LIMIT
  100

with active_users as (select id from users where status='active') select o.id, o.total, u.email from orders o join active_users au on o.user_id=au.id join users u on u.id=au.id where o.created_at >= now() - interval '7 days' returning *

WITH active_users AS (
  SELECT
    id
  FROM
    users
  WHERE
    status = 'active'
)
SELECT
  o.id,
  o.total,
  u.email
FROM
  orders o
  JOIN active_users au ON o.user_id = au.id
  JOIN users u ON u.id = au.id
WHERE
  o.created_at >= now() - INTERVAL '7 days'
RETURNING
  *

SELECT * FROM events QUALIFY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) = 1

(parses cleanly with Snowflake or BigQuery dialect; loses structure with PostgreSQL since it has no QUALIFY clause)

FAQ

Related concepts

SQL was first standardized in 1986 (ANSI SQL-86) and is now in revision SQL:2023, but every major engine carries its own dialect on top of the standard. The differences are not cosmetic: a query that runs on Snowflake may not parse on PostgreSQL because of `QUALIFY`, `LATERAL FLATTEN`, or `:` variable substitution; a T-SQL batch with `GO` separators and `DECLARE @x` is meaningless to MySQL. A dialect-aware formatter parses the query against the chosen grammar and re-prints it, preserving constructs the standard does not know.

Formatting is one of three nearby disciplines. **Formatting** restructures whitespace and case while keeping the query semantically identical — this tool. **Linting** flags style or correctness smells (`sqlfluff`, `sqlint`, the Snowflake `dbt` linter) such as unqualified `*`, unused CTEs, or implicit type coercions. **Static analysis** goes further (`squawk`, `eversql`, `pganalyze`) to read query plans and warn about missing indexes or table-locking DDL. Formatters are safe to run automatically on every commit; linters fit pre-commit hooks; analyzers usually run against a real planner.

Three adjacent SQL writing conventions are worth recognizing. **Leading commas** (`, column_a` instead of `column_a,`) make adding lines diff-friendly and are used by Mode, Hashicorp, and several data team style guides — `sql-formatter` does not enforce this. **River formatting** vertically aligns clause keywords (`SELECT`, `FROM`, `WHERE` all right-aligned to a common column) — common in older Oracle shops and rejected by most modern guides for being hard to maintain. **Stack formatting** is what this tool produces by default — clause header on its own line, contents indented below. Pick the style your team reads fastest in pull requests, then let the formatter enforce it.