Which SQL dialects are supported?

Standard SQL, MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), Oracle PL/SQL, SQLite, BigQuery, Snowflake, Amazon Redshift, Spark SQL and IBM Db2. Choosing the right dialect matters for things like T-SQL’s [brackets], PostgreSQL’s :: casts and MySQL’s backticks.

Does formatting change what my query does?

No. Only whitespace, line breaks and — if you choose — the case of keywords change. Identifiers, strings and comments are kept exactly as written.

Why do I get a parse error for a valid query?

The query probably uses syntax that the selected dialect doesn’t know, such as a vendor-specific keyword or operator. Switch to the dialect of your database. Unusual syntax like some stored-procedure code may not be supported by any dialect.

Should SQL keywords be uppercase?

SQL is case-insensitive, so it’s a style choice. Uppercase keywords (SELECT, FROM, WHERE) are the most common convention because they stand out from table and column names. Pick “As written” to keep your own style.

No. The formatter runs in your browser and is only downloaded when you use this page. Queries often contain table names and data you shouldn’t share — they never leave your device.

SQL Formatter

This SQL formatter gives any query clean line breaks, indentation and consistent keyword case.

SQL input

select o.id, c.name as customer, sum(i.quantity * i.price) as total from orders o join customers c on c.id = o.customer_id left join order_items i on i.order_id = o.id where o.created_at >= '2026-01-01' and o.status in ('paid', 'shipped') group by o.id, c.name having sum(i.quantity * i.price) > 100 order by total desc limit 20;

Formatted SQL

SELECT
  o.id,
  c.name AS customer,
  sum(i.quantity * i.price) AS total
FROM
  orders o
  JOIN customers c ON c.id = o.customer_id
  LEFT JOIN order_items i ON i.order_id = o.id
WHERE
  o.created_at >= '2026-01-01'
  AND o.status IN ('paid', 'shipped')
GROUP BY
  o.id,
  c.name
HAVING
  sum(i.quantity * i.price) > 100
ORDER BY
  total DESC
LIMIT
  20;

SELECT
  o.id,
  c.name AS customer,
  sum(i.quantity * i.price) AS total
FROM
  orders o
  JOIN customers c ON c.id = o.customer_id
  LEFT JOIN order_items i ON i.order_id = o.id
WHERE
  o.created_at >= '2026-01-01'
  AND o.status IN ('paid', 'shipped')
GROUP BY
  o.id,
  c.name
HAVING
  sum(i.quantity * i.price) > 100
ORDER BY
  total DESC
LIMIT
  20;

How to format SQL

Paste your query on the left, or open a .sql file.
Pick your database's dialect, the keyword case and the indentation.
The formatted SQL appears on the right. Copy it or Download it as a .sql file.

Before and after

One long line

select id, name from users where active = 1 and created_at > '2026-01-01' order by name

Formatted, uppercase keywords, 2 spaces

SELECT
  id,
  name
FROM
  users
WHERE
  active = 1
  AND created_at > '2026-01-01'
ORDER BY
  name

Why the dialect matters

Each database extends SQL with its own syntax: SQL Server quotes names in [brackets] and uses TOP, MySQL uses `backticks`, PostgreSQL has :: casts and $1 parameters, and BigQuery writes tables as `project.dataset.table`. With the right dialect, the formatter recognises these and lays them out correctly instead of reporting an error.

A readable SQL style

Each clause — SELECT, FROM, WHERE, GROUP BY, ORDER BY — starts a new line.
Selected columns and conditions are indented one level, one per line.
Subqueries are indented inside their parentheses, so nesting is visible.
Keywords in one consistent case, so they stand out from names.

Formatted queries are easier to review in pull requests and to compare — paste the old and new version into the diff checker to see exactly what changed.

Other formatters

Format API responses with the JSON formatter, scripts with the JavaScript formatter and stylesheets with the CSS formatter.

Frequently asked questions

Which SQL dialects are supported?: Standard SQL, MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), Oracle PL/SQL, SQLite, BigQuery, Snowflake, Amazon Redshift, Spark SQL and IBM Db2. Choosing the right dialect matters for things like T-SQL’s [brackets], PostgreSQL’s :: casts and MySQL’s backticks.
Does formatting change what my query does?: No. Only whitespace, line breaks and — if you choose — the case of keywords change. Identifiers, strings and comments are kept exactly as written.
Why do I get a parse error for a valid query?: The query probably uses syntax that the selected dialect doesn’t know, such as a vendor-specific keyword or operator. Switch to the dialect of your database. Unusual syntax like some stored-procedure code may not be supported by any dialect.
Should SQL keywords be uppercase?: SQL is case-insensitive, so it’s a style choice. Uppercase keywords (SELECT, FROM, WHERE) are the most common convention because they stand out from table and column names. Pick “As written” to keep your own style.
Is my SQL uploaded?: No. The formatter runs in your browser and is only downloaded when you use this page. Queries often contain table names and data you shouldn’t share — they never leave your device.