SQL Formatter

Format and beautify SQL queries with various styles and conventions

Raw SQL

Lines: 1 | Characters: 0

Formatted SQL

Lines: 0 | Characters: 0

Formatting Style

Advanced Settings

SQL Examples

History

About the SQL Formatter & Beautifier

Anyone who has scrolled through a 400-character SQL query jammed onto a single line knows the pain this tool solves. A stored procedure export, a query copied from a Slack thread, or a minified statement pulled from an application log often arrives with no line breaks, inconsistent capitalization, and clauses packed together in a way that makes it nearly impossible to spot a missing JOIN condition or a misplaced parenthesis. The SQL Formatter takes that raw text and rebuilds it into a properly indented, readable query so you can actually see its structure — SELECT list, FROM, WHERE, GROUP BY, and nested subqueries each landing on their own visually distinct block.

Paste or type a query and the output updates as you type: in the Standard style SELECT, FROM, WHERE, GROUP BY, ORDER BY and HAVING each start a new line, JOINs break onto their own lines, each column in the SELECT list gets its own line, and every parenthesis indents its contents one level so subqueries stand out. Expanded also breaks after every comma, while Compact only wraps at the maximum line length. You choose keyword case (UPPERCASE, lowercase or Title Case), spaces or tabs, the indent width, and whether comments are stripped. It is a lightweight tokenizer rather than a full SQL parser, so it formats standard SELECT, INSERT, UPDATE and CTE queries well but does not know dialect-specific syntax; the Oracle, MySQL, PostgreSQL and SQL Server presets currently produce the same layout as Compact.

Formatting happens in your browser, so the query text is not sent anywhere — which matters when the SQL contains internal table names or business logic. Your settings, and the last 20 queries you copied, are kept in local storage; Clear History removes them. A common workflow is formatting a query before a code review or before adding it to a migration file, since consistent indentation makes diffs in version control far easier to read than one squashed onto a single line.

How to format a SQL query

Turn a dense or minified SQL query into a cleanly indented, readable statement.

  1. 1

    Paste your SQL

    Copy the query from your database client, log file, or codebase and paste it into the input box.

  2. 2

    Pick a formatting style

    Choose Standard for one clause per line, Expanded to also break after every comma, or Compact to keep clauses together and wrap only at the maximum line length.

  3. 3

    Adjust the settings

    Under Advanced Settings, set keyword case, spaces or tabs, indent width and maximum line length. The formatted output updates automatically about half a second after each change.

  4. 4

    Review the structure

    Read through the output before using it: check that subqueries are indented as expected and that nothing dialect-specific (backslash escapes, dollar-quoted bodies) was rearranged.

  5. 5

    Copy the result

    Copy the cleaned-up query and paste it back into your SQL file, migration script, or code review.

Worked examples

A one-line report query, Standard style

Input
SELECT customer_id, SUM(total) AS spent FROM orders WHERE status = 'paid' GROUP BY customer_id ORDER BY spent DESC;
Result
SELECT customer_id, SUM(total) AS spent FROM orders WHERE status = 'paid' GROUP BY customer_id ORDER BY spent DESC;

SELECT, FROM, WHERE, GROUP BY, ORDER BY and HAVING each start a new line, and with Align Columns on, every comma in the SELECT list starts a new line too.

A subquery, lowercase keywords, 4-space indent

Input
select name from products where price > (select avg(price) from products where category_id = 1) and stock_quantity > 0; Keyword Case: lowercase, Indentation: Spaces, 4
Result
select name from products where price >( select avg(price) from products where category_id = 1) and stock_quantity > 0;

Each open parenthesis adds one indent level, so the inner query sits one step in from the outer one.

Compact keeps the clauses on one line

Input
The first query again, with the Compact style.
Result
SELECT customer_id, SUM(total) AS spent FROM orders WHERE status = 'paid' GROUP BY customer_id ORDER BY spent DESC;

Compact only wraps when a line passes Max Line Length (80 by default). The Oracle, MySQL, PostgreSQL and SQL Server styles currently produce this same compact layout.

Tips and common mistakes

  • There is no Format button: the output updates about half a second after you stop typing, and again whenever you change a setting.
  • This is a lightweight tokenizer, not a full SQL parser, so read the output before you run it. It keeps two-character operators (>=, <=, <>, !=, ||, ::) intact, writes qualified names and function calls without extra spaces (u.id, COUNT(o.id)) and keeps LEFT JOIN, INNER JOIN and CROSS JOIN on one line, but it knows nothing about dialect-specific syntax.
  • Strings are recognised in single or double quotes, and a doubled quote inside a single-quoted string ('O''Brien') stays part of the string. Backslash escapes and dollar-quoted PostgreSQL bodies are not understood, so keep stored procedures and function bodies out of it.
  • Leave Remove Comments off unless you want them gone. When it is on, every "--" to the end of a line is deleted, including a "--" that happens to sit inside a string literal.
  • Settings are stored in your browser's local storage, and each time you copy a result it is added to History (the last 20 are kept). Clear History removes them if you have pasted anything sensitive on a shared computer.
  • "Use output as input" copies the formatted text back into the Raw SQL box, which is handy for trying a different style on an already-cleaned query.

Frequently Asked Questions

What SQL dialects does the formatter support?

It handles the standard SQL that all major databases share: SELECT, INSERT, UPDATE, DELETE, JOINs, subqueries and WITH (CTE) queries. The Oracle, MySQL, PostgreSQL and SQL Server style buttons do not add dialect-specific rules; they currently produce the same layout as Compact. Dialect features such as PostgreSQL dollar-quoted function bodies are not understood.

Does the formatter change the logic of my query?

It is meant to change only whitespace, line breaks and keyword case. Operators such as >=, <> and ::, qualified names like u.id, and strings with a doubled quote ('O''Brien') are kept intact. It is still a simple tokenizer rather than a parser, so check the result before running it — and note that Remove Comments deletes anything after -- on a line, even inside a string.

Can I minify SQL as well as format it?

Not fully. The Compact style keeps clauses on the same line and wraps only at the Max Line Length, but it still starts a new line after each comma in the SELECT list. For a true one-line query, use Compact, turn off Align Columns and raise Max Line Length (the maximum is 200 characters); queries longer than that will still wrap.

Does the formatter check whether my SQL is valid?

No. It only rearranges whitespace and keyword case, and it will happily format a query with a typo in it. The SQL Analysis panel shows the query type, a keyword count and a count of FROM tables, but it does not validate syntax. For MySQL queries, the MySQL Syntax Check tool on this site looks for common structural mistakes such as unbalanced quotes and parentheses or a trailing comma before FROM.

Which keywords get their case changed?

A fixed list of about 70 common words: clause keywords (SELECT, FROM, WHERE, JOIN, GROUP, ORDER, HAVING, UNION, WITH), operators (AND, OR, NOT, IN, LIKE, BETWEEN, IS, NULL), DML and DDL words (INSERT, UPDATE, DELETE, CREATE, ALTER, DROP) and the aggregates COUNT, SUM, AVG, MIN and MAX. Words outside the list, such as DESC, LIMIT or COALESCE, are left exactly as you typed them.

Related guide

How to Pretty Print SQL: Format Messy Queries in Seconds