SQL Formatter

What is a SQL formatter?#

A SQL formatter turns a query that was written for the engine — often crammed onto one line, or pasted out of a log with random indentation — into a query written for a human. Keywords go on their own lines, columns line up, subqueries step in one level, and a WHERE clause with five AND conditions stops being a wall of text. The reverse operation, minifying, collapses all of that whitespace back to a single line for when a query needs to travel through a config file or an API parameter.

What makes SQL formatting fiddly is that every database has its own dialect. A Postgres query with RETURNING, a MySQL query with backtick-quoted identifiers, a SQL Server query with TOP (n), and a BigQuery query with struct and array literals all look different, and a formatter that pretends there is one universal SQL will get the edge cases subtly wrong. This page handles that by using sql-formatter with explicit dialect selection: standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, PL/SQL, BigQuery, Redshift, Snowflake, DB2 and Trino. You pick the one your database actually speaks, and the formatter parses accordingly.

How to use it#

1. Paste your query into the SQL pane on the left, or click Sample to load a short example.
2. Pick a Language on the toolbar — the dialect of your database. The default sql is a safe generic flavour; switch to postgresql, mysql, tsql and so on when the query uses dialect-specific syntax.
3. Choose an Indent: 2, 4, or tab. Four spaces is common for SQL because it keeps long column lists readable.
4. Click an action:
   • Format — re-indent, break the query onto logical lines, and uppercase keywords by default so SELECT, FROM and WHERE stand out from identifiers.
   • Minify — strip -- line comments and /* */ block comments, then collapse every run of whitespace to a single space. Newlines become spaces, which is safe for SQL because statements end on a semicolon, not a newline.
5. Read the result in the Output pane. Use Copy to grab it; Clear resets both panes.

Key features#

• Twelve dialects. MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, PL/SQL, BigQuery, Redshift, Snowflake, DB2, Trino, plus generic standard SQL. The formatter’s grammar changes to match, so dialect-specific keywords are positioned correctly.
• Keyword casing. Format uppercases keywords by default (so select becomes SELECT) and leaves your identifiers alone. This is purely cosmetic and never changes what the query does.
• Safe minify. Whitespace collapses to single spaces; SQL is semicolon-terminated, so joining lines cannot fuse two statements the way it can in newline-sensitive languages.
• Comment stripping on minify. Both -- and /* */ comments are removed when you minify, keeping the payload tight.
• Two-pane, copy-ready, fully client-side. The formatter runs in your browser; the query is not sent anywhere.

Worked example#

A reporting query dumped onto one line, with a comment, a join, and a GROUP BY:

Input:

select u.id,u.name,count(o.id) as orders from users u join orders o on o.user_id=u.id where u.status='active' and o.created_at >= '2026-01-01' group by u.id,u.name order by orders desc

Pick postgresql as the Language, then click Format with 2 spaces:

SELECT
  u.id,
  u.name,
  count(o.id) AS orders
FROM
  users u
  JOIN orders o ON o.user_id = u.id
WHERE
  u.status = 'active'
  AND o.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.name
ORDER BY
  orders DESC

Every clause now has its own line, the join condition is visible, and the two WHERE predicates are split so you can tell at a glance that the date filter is >=, not >. The keyword casing went to upper case while the column names stayed exactly as written. Click Minify on the same input and you get the one-line form back, ready to paste into a config or a ?query= parameter:

select u.id,u.name,count(o.id) as orders from users u join orders o on o.user_id=u.id where u.status='active' and o.created_at >= '2026-01-01' group by u.id,u.name order by orders desc

FAQ#

Which dialect should I pick?#

Match your database. If you are unsure, generic sql is a reasonable starting point and handles the common clauses correctly. Switch to the specific dialect when the query uses syntax the generic grammar does not expect — RETURNING (Postgres), backtick identifiers (MySQL), TOP (n) (T-SQL), or struct/array literals (BigQuery). Picking the wrong dialect usually still formats, but may misplace an exotic keyword.

Why does Format uppercase keywords but not my column names?#

Because uppercasing keywords is a readability convention that never changes meaning — SELECT and select are identical to the engine — while your identifiers may be case-sensitive (Postgres folds unquoted identifiers to lower case; MySQL is case-sensitive on some platforms). Leaving identifiers alone is the safe default. If you prefer lowercase keywords, format the query and then do a manual pass.

Does minify preserve multi-statement scripts?#

It collapses each run of whitespace to a single space, including newlines, but it keeps semicolons exactly where they were. So SELECT 1; SELECT 2; stays as two statements separated by ;. That said, for a long migration script with many statements, a single-line minified form is hard to read and hard to debug — minify suits a single query or a short batch.

Is my query uploaded anywhere?#

No. The formatter is bundled into the page and runs locally in your browser. Nothing about your SQL — not the table names, not the literals — leaves the tab.