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 and WHERE clauses that scroll off the screen. This formatter gives that line a shape you can scan. It starts each major clause — SELECT, FROM, WHERE, the JOIN variants, GROUP BY, HAVING, ORDER BY, LIMIT, OFFSET, UNION, INSERT INTO, VALUES, UPDATE, SET, DELETE FROM, CREATE, DROP and ALTER TABLE — on a new line, puts each comma-separated item outside parentheses on its own indented line, and uppercases a fixed list of common keywords such as AS, AND, OR, IN, LIKE and CASE. Text inside quotes and comments is never changed. It is a lightweight line-breaker rather than a full SQL parser: there is no dialect setting, subqueries and CTEs are not indented, and operators keep their original spacing. A Minify button collapses the query back to one line and strips comments. Formatting runs in the browser, so queries stay private.

Why use it

• Clause-by-Clause Layout: Each major SQL clause — SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT — starts on its own line, so missing conditions or joins are easier to spot than in a single long line.

• One Column per Line: Commas outside parentheses become line breaks with a two-space indent, so long SELECT lists and SET assignments read as a vertical list while function arguments stay together.

• Keyword Uppercasing: Common keywords such as SELECT, FROM, AS, AND, OR, IN, LIKE, CASE and NOT NULL are uppercased for contrast with identifiers; words outside that list keep the case you typed.

• Strings and Comments Untouched: Text inside single quotes, double quotes, backticks and comments is skipped, so a value like 'select, from' is never split or uppercased.

• 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 box
2. Click Format SQL to break the query into one clause per line
3. Review the output — top-level columns sit on indented lines and known keywords are uppercased
4. Click Minify instead if you want a single line with comments removed
5. Copy the result and paste it into your database client, migration file, or code review

When it helps

• You are reviewing a query generated by an ORM and want its clauses on separate lines before checking the logic
• A slow query log arrived as a single unbroken line and you need to read it
• You are pasting a query into a pull request or documentation and want each clause on its own line
• You are debugging a query built dynamically by application code and want to see its overall structure
• You need to collapse a formatted query back to one line with comments removed

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

select dept,count(*) as n from employees group by dept having count(*)>5 order by n desc

SELECT dept,
  count(*) AS n 
FROM employees 
GROUP BY dept 
HAVING count(*)>5 
ORDER BY n desc

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 — one clause per line is easier to correlate with the execution plan nodes.
• The formatter does not indent subqueries; add indentation by hand when you paste a nested query into documentation.
• Window functions are not special-cased: an ORDER BY inside OVER(...) is also moved to a new line, so tidy those lines by hand.
• 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. DML statements (SELECT, INSERT, UPDATE, DELETE) change or read the data itself.