SQL Formatter

About this tool

SQL written by query builders, ORMs, and log exporters arrives as a single unbroken line: keywords jammed against table names, subqueries nested four levels deep, and WHERE clauses that scroll off the screen. Reading unformatted SQL to debug a slow query or review a migration is one of the most frustrating tasks in backend development. This tool takes any SQL statement — SELECT, INSERT, UPDATE, DELETE, CREATE, or complex multi-join queries — and formats it into indented, keyword-capitalized, clause-aligned SQL that you can actually read. Each major clause starts on its own line. Nested subqueries are indented to show their scope. Window functions and CTEs are formatted with their own indentation levels. The output supports MySQL, PostgreSQL, SQL Server, and standard ANSI SQL dialects. Formatting runs in the browser so queries stay private.

Why use it

• Clause-by-Clause Layout: Each SQL clause — SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT — starts on its own line with consistent indentation. Reading query structure and spotting missing conditions or joins becomes immediate rather than requiring careful scanning.

• Subquery Indentation: Nested subqueries are indented relative to their parent query, making it clear which SELECT belongs to which level. Deep nesting that is impossible to follow in a single line becomes visually obvious in the formatted output.

• CTE Support: Common Table Expressions introduced with the WITH keyword are formatted with each CTE on its own named block and the final query below, reflecting the logical execution order and making recursive CTEs readable.

• Multi-Dialect Aware: Formatting rules adapt to MySQL, PostgreSQL, SQL Server, and SQLite dialects. Dialect-specific syntax like LIMIT/OFFSET, TOP, and PostgreSQL dollar-quoting is handled correctly without mangling keyword detection.

• Keyword Capitalization: SQL keywords can be normalized to uppercase, lowercase, or left as-is. Uppercase is the most widely used convention and maximizes visual contrast between keywords and identifiers in code review.

• Browser-Local: Formatting runs entirely in your browser. SQL queries that include table names, column values, or embedded data from production databases never leave your machine.

How to use

1. Paste your raw or minified SQL into the input editor
2. Select your SQL dialect: MySQL, PostgreSQL, SQL Server, or ANSI
3. Choose keyword capitalization: uppercase (SELECT), lowercase (select), or preserve original
4. Click Format to produce indented, clause-aligned SQL
5. Review the output to confirm subquery indentation and JOIN alignment are correct
6. Copy the formatted SQL and paste it into your database client, migration file, or code review

When it helps

• You are reviewing a migration script generated by an ORM and need to verify query logic before running it
• A slow query log or EXPLAIN output arrived as a single unbroken line and you need to read it
• You are writing a complex multi-join query and want to format it for inclusion in a pull request or documentation
• You inherited a legacy stored procedure and need to understand its structure before modifying it
• You are debugging a query built dynamically by application code and want to see its formatted structure
• You want to standardize keyword casing and indentation across SQL files in a codebase

Examples

select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where u.active=1 order by o.total desc

SELECT
  u.id,
  u.name,
  o.total
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE u.active = 1
ORDER BY o.total DESC

with ranked as (select id,name,row_number() over(partition by dept order by salary desc) as rn from employees) select * from ranked where rn=1

WITH ranked AS (
  SELECT
    id,
    name,
    ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn
  FROM employees
)
SELECT *
FROM ranked
WHERE rn = 1

select * from users where id in (select user_id from orders where total > 100)

SELECT *
FROM users
WHERE id IN (
  SELECT user_id
  FROM orders
  WHERE total > 100
)

Tips

• Format queries before running EXPLAIN or EXPLAIN ANALYZE — structured output is much easier to correlate with the execution plan nodes.
• Use uppercase keywords in code committed to version control — the visual contrast between keywords and identifiers makes code reviews faster.
• For CTEs, give each expression a descriptive name before formatting — formatted CTEs expose poor naming that was hidden in inline subqueries.
• When reviewing ORM-generated SQL, format it to check for N+1 patterns, missing indexes on JOIN columns, and unintended Cartesian joins.
• Strip sensitive column values from queries before sharing formatted output in bug reports or Slack messages.

Frequently Asked Questions

Glossary

CTE

Common Table Expression — a named temporary result set defined with the WITH keyword before a SELECT, INSERT, UPDATE, or DELETE statement. CTEs improve readability by naming subqueries.

Window function

A SQL function that operates over a set of rows related to the current row, defined with the OVER clause. Examples include RANK(), ROW_NUMBER(), and LAG(). They do not collapse rows like aggregate functions.

Subquery

A SELECT statement nested inside another SQL statement. Subqueries can appear in the FROM clause as a derived table, in the WHERE clause as a condition, or in the SELECT list as a scalar subquery.

Dialect

A vendor-specific variant of SQL with proprietary extensions and syntax differences. Major dialects include MySQL, PostgreSQL, SQL Server (T-SQL), Oracle, and SQLite.

EXPLAIN

A SQL command prefix that shows the query execution plan without running the query, used to diagnose slow query performance. PostgreSQL's EXPLAIN ANALYZE also executes the query and reports actual timings.

DDL

Data Definition Language — SQL statements that define database structure: CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX. DDL is formatted alongside DML (SELECT, INSERT, UPDATE, DELETE).