SQL Formatter / Beautifier

Processed Client Side

Beautify or minify SQL queries. Detects the dialect, indents clauses and joins, and normalises keyword case — all in your browser.

Input · 1 lines · 359 chars

with monthly as (select date_trunc('month',created_at) as m,user_id,sum(total) as spend from orders where status='paid' and total between 10 and 1000 group by 1,2) select m,user_id,spend,rank() over (partition by m order by spend desc) as rnk from monthly m join users u on u.id=m.user_id where spend>0 and (u.plan='pro' or u.seats>5) order by m,rnk limit 50;

SQLLength: 359Lines: 1Size: 359 BytesCursor: 1:1

Output

Beautified

WITH monthly AS (
  SELECT DATE_TRUNC('month', created_at) AS m, user_id, SUM(total) AS spend
  FROM orders
  WHERE status = 'paid'
    AND total BETWEEN 10 AND 1000
  GROUP BY 1, 2
)
SELECT
  m,
  user_id,
  spend,
  RANK() OVER (PARTITION BY m ORDER BY spend DESC) AS rnk
FROM monthly m
JOIN users u
  ON u.id = m.user_id
WHERE spend > 0
  AND (u.plan = 'pro' OR u.seats > 5)
ORDER BY m, rnk
LIMIT 50;

WITH monthly AS (
  SELECT DATE_TRUNC('month', created_at) AS m, user_id, SUM(total) AS spend
  FROM orders
  WHERE status = 'paid'
    AND total BETWEEN 10 AND 1000
  GROUP BY 1, 2
)
SELECT
  m,
  user_id,
  spend,
  RANK() OVER (PARTITION BY m ORDER BY spend DESC) AS rnk
FROM monthly m
JOIN users u
  ON u.id = m.user_id
WHERE spend > 0
  AND (u.plan = 'pro' OR u.seats > 5)
ORDER BY m, rnk
LIMIT 50;

SQLLength: 403Lines: 19Size: 403 BytesCursor: 1:1

No dialect markers — using standard SQL1 statement2 tables: orders, users1 join1 subquery

Bookmark this tool now — skip the search next time you need it.

About SQL Formatter / Beautifier

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

The SQL Formatter takes a query that arrived as one unreadable line — out of a slow-query log, an ORM, or a bug report — and lays it out so you can follow it. Clauses start their own lines, each join sits above its own ON predicate, boolean conditions stack under WHERE, and subqueries indent inside their parentheses. Minify does the reverse, squeezing a statement back onto one line for a config file or a connection string. It works out the dialect from the markers in your SQL and says what it decided, so you can overrule it. Everything runs in your browser.

Key features

Beautify and minify from one toggle, re-running on every keystroke
Automatic dialect detection for MySQL, PostgreSQL, SQLite, SQL Server and Oracle, shown beside the result
Clause-aware layout: SELECT, FROM, WHERE, GROUP BY, joins, CTEs and set operators each begin their own line
AND and OR lead their own line under WHERE and ON, while a BETWEEN keeps its AND
Lists stay on one line while they fit, break one item per line, or never break in Compact mode
One column definition per line in CREATE TABLE, one row tuple per line in a multi-row INSERT
CASE stays inline when short and indents its WHEN branches when long
Keyword case set to UPPER, lower, or left as written — quoted identifiers are never re-cased
Comments kept on the line they described, and optimizer hints survive minification
A statistics row reporting statements, tables referenced, joins, subqueries and comments
Syntax highlighting in both panes, copy to clipboard, download as .sql, and nothing uploaded

How to use it

Paste your SQL into the left pane, replacing the sample.
Leave Dialect on Auto detect, or pick one if your snippet has no dialect-specific syntax.
Choose Beautify to expand the query, or Minify to squeeze it onto one line.
For Beautify, set the indentation, keyword case, and how eagerly lists break.
Read the result on the right, and the badges under it for the dialect and statistics.
Copy the output, or download it as a .sql file.

Tips & common mistakes

The dialect changes how your SQL is read, not how it is laid out: whether # opens a comment, whether [name] is an identifier, whether $$ quotes a body. The indentation rules are identical for every dialect.
Auto detect scores dialect markers, and only inside real code — AUTO_INCREMENT sitting in a string literal is ignored. A query with no markers says so rather than guessing, and picking a dialect yourself always wins.
Minify removes whitespace and comments and nothing else. It does not rename anything, reorder joins, or rewrite your query into a faster one, so the saving is in bytes, not execution time.
Hints survive minification. A comment opening with a plus is an optimizer hint, and one opening with an exclamation mark is version-gated MySQL that executes — dropping either changes what the database does.
Re-casing keywords is safe for unquoted names, which these engines case-fold anyway. Anything inside backticks, double quotes, or brackets passes through character for character.
Columns are deliberately not aligned into a second column: alignment depends on the width of the keyword before it, so it breaks under lower-case keywords or tabs and re-flows on every rename.
This is a formatter, not a validator: broken SQL still formats, and output that indents unexpectedly usually points straight at a parenthesis you forgot to close.
The table list is a token heuristic, not name resolution: it reads the identifier after FROM, a JOIN, INSERT INTO, UPDATE or DELETE FROM and drops CTE names.

Related tools

SQL Schema Diff SQL Parameter Replacer

Browse all 3 Database tools

Frequently asked questions

Paste the query into the left pane and the formatted version appears on the right immediately, updating as you type. Choose your indentation and keyword case in the toolbar, then copy the result or download it as a .sql file. Nothing is uploaded — the formatting runs in your browser.

MySQL, PostgreSQL, SQLite, SQL Server and Oracle, plus a plain standard-SQL mode. Auto detect is on by default and reports which one it picked. The dialect affects how your SQL is read — comment markers, identifier quoting, dollar-quoted bodies, string escapes — rather than how it is indented, because the layout rules are the same everywhere.

It scores dialect-specific markers in your code: backticks and AUTO_INCREMENT point at MySQL, a :: cast or a $$ body at PostgreSQL, [bracket] identifiers and TOP at SQL Server, VARCHAR2 and DUAL at Oracle, PRAGMA at SQLite. Markers inside strings and comments are ignored. If nothing distinctive turns up it says so rather than guessing, and choosing a dialect from the selector overrides it entirely.

Yes. Switch the toggle to Minify and the query collapses to a single line with comments removed, which is what you want for a config value, an environment variable, or a connection string. Semicolons are kept, so a multi-statement script still runs afterwards.

No. Minifying removes whitespace and comments and nothing else — it does not rename anything, reorder joins, add indexes, or rewrite the query plan. The database parses the formatted and minified versions into exactly the same thing, so the saving is in bytes transferred, not in execution time.

No. Only keywords are re-cased, and only when you ask for UPPER or lower. Identifiers are left alone, and anything inside backticks, double quotes or square brackets is passed through character for character — which matters, because quoted identifiers are the only ones these engines treat as case-sensitive.

When beautifying, yes. A comment written above a clause stays above it at the same indentation, and a comment trailing a line stays on that line. Line comments, block comments, and MySQL # comments are all understood. Minifying removes them, with one exception: optimizer hints and MySQL version-gated comments are executable code and are always kept.

Because it fits. In Auto mode a list stays on one line while it is under 80 characters and breaks one item per line when it is not. Set Line breaks to "One item per line" to break every list regardless, or "Compact" to keep lists together no matter how wide they get.

No, and that is deliberate — you are usually formatting a query that is half-written. Invalid SQL still formats rather than being rejected. That said, the output is a useful hint: a block that indents somewhere surprising almost always marks a parenthesis or a quote you did not close, and unbalanced parentheses and unterminated strings do get flagged.

No. The tokenizer and formatter are JavaScript running in your browser tab, and there is no request to send a query anywhere. That is the reason this is safe to use on production SQL containing real table names, customer identifiers, or literals from a live database.