How to Format SQL: A Complete Guide to Clean Queries

Copy a query out of your app logs or an ORM's debug output and you usually get a wall of SQL on a single line. It runs fine — but reading it, reviewing it, or spotting the bug is painful. A SQL formatter rewrites that query with consistent indentation, casing, and line breaks so a human can actually read it.

You can try every example below in the SQL Formatter — it runs entirely in your browser, so even production queries never leave your machine.

Before and after

Here's a typical one-liner:

select u.id,u.name,o.total from users u join orders o on u.id=o.user_id where o.status='paid' and o.total>100 order by o.total desc limit 20

And the same query, formatted:

SELECT
  u.id,
  u.name,
  o.total
FROM
  users u
  JOIN orders o ON u.id = o.user_id
WHERE
  o.status = 'paid'
  AND o.total > 100
ORDER BY
  o.total DESC
LIMIT
  20

Same query, but now the clauses, joins, and conditions are obvious at a glance.

Step 1: Pick your dialect

SQL isn't one language — every database has its own keywords, functions, and quoting rules. The formatter supports 11 dialects:

Dialect	Use for
Standard SQL	Generic / ANSI SQL
PostgreSQL	Postgres, Supabase, CockroachDB
MySQL / MariaDB	MySQL, MariaDB, PlanetScale
SQLite	SQLite, local/embedded databases
SQL Server (T-SQL)	Microsoft SQL Server, Azure SQL
Oracle (PL/SQL)	Oracle Database
BigQuery	Google BigQuery
Redshift	Amazon Redshift
Spark SQL	Apache Spark, Databricks
Snowflake	Snowflake

Choosing the right dialect ensures dialect-specific keywords (like ILIKE, QUALIFY, or MERGE) and identifier quoting are handled correctly instead of being mangled.

Step 2: Control the casing

Casing is where teams disagree most, so each token type has its own control — set any of them to UPPERCASE, lowercase, or Preserve:

• Keywords — SELECT, FROM, WHERE (uppercase is the classic convention)
• Data types — INT, VARCHAR, TIMESTAMP
• Functions — COUNT, COALESCE, NOW
• Identifiers — your table and column names

A common house style is uppercase keywords and data types, but preserved identifiers so userId stays userId rather than becoming USERID:

SELECT
  userId,
  COUNT(*) AS total
FROM
  Orders
WHERE
  createdAt > NOW() - INTERVAL '7 days'
GROUP BY
  userId

Step 3: Tune the indentation

• Indent width — 2 spaces is common; bump to 4 if your team prefers, or switch on Use tabs.
• Indent style — Standard is the usual block indentation. Tabular aligns the first keyword of each clause into a fixed-width column, which some people prefer for scanning:

SELECT    u.id,
          u.name
FROM      users u
WHERE     u.active = 1
ORDER BY  u.name

Step 4: Choose where AND / OR go

The logical operator newline option decides whether boolean operators start or end a line. Leading operators (the default) make it easy to comment out a single condition:

-- AND/OR at the start of the line (before)
WHERE
  status = 'paid'
  AND total > 100
  AND created_at > '2026-01-01'

-- AND/OR at the end of the line (after)
WHERE
  status = 'paid' AND
  total > 100 AND
  created_at > '2026-01-01'

Step 5: Manage line length

Expression width sets how many characters an expression can reach before it wraps onto multiple lines. Lower it for narrow side-by-side diffs; raise it if you'd rather keep short expressions on one line. Dense operators removes the spaces around operators (a=1 instead of a = 1) when you want a more compact result.

Minifying: the opposite of formatting

Sometimes you need the query smaller, not prettier — for example to paste it into a JSON config, a one-line shell command, or a code string. The Minify button collapses the query onto a single line: it strips comments and reduces runs of whitespace, while carefully preserving the contents of quoted strings and identifiers.

SELECT id, name FROM users WHERE active = 1 -- only active

becomes

SELECT id, name FROM users WHERE active = 1

Format as you type

Turn on Auto-format and the output updates on every keystroke (debounced), so you can paste a query and immediately keep editing in formatted form. Prefer to format on demand? Leave it off and click Format when you're ready.

Everything stays in your browser

The formatter runs 100% client-side. No query — however sensitive — is ever uploaded to a server, so it's safe to paste real production SQL, credentials in comments, or internal table names.

Next: comparing two queries

Formatting one query is half the story. When you're reviewing a change — a migration, a refactor, an edited report — you want to see what changed between two versions. That's exactly what the companion tool does: read How to Compare Two SQL Queries or jump straight into SQL Compare.