SQL Formatter and Beautifier

A SQL formatter reads your query as a stream of tokens (keywords, identifiers, strings, operators, comments) and prints it again with consistent line breaks and indentation. Only whitespace and, if you ask for it, the letter case of keywords change. String literals, quoted identifiers and comments come out exactly as they went in, so the formatted query returns the same rows.

-- Before
select u.id,u.email,count(o.id) orders from users u left join orders o on o.user_id=u.id where u.active group by 1,2

-- After
SELECT
  u.id,
  u.email,
  count(o.id) orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.active
GROUP BY
  1,
  2

Formatting is also a cheap syntax check: if the formatter cannot parse a statement, you get the line and column of the first token it could not place, which is usually an unclosed quote, a stray parenthesis or the wrong dialect.

Both are correct: SQL keywords are case-insensitive in every major database. The choice is about readability and team habit.

• Uppercase (SELECT, LEFT JOIN) is the traditional style and what the widely shared SQL Style Guide recommends. Keywords stand out from table and column names even in plain text, in logs and in code review tools without syntax highlighting.
• Lowercase (select, left join) is popular in analytics and application code, where editors already color keywords and capitals feel like shouting.

Pick one and apply it everywhere, which is exactly what a formatter is for. Be more careful with identifier case: PostgreSQL folds unquoted names to lowercase, but MySQL table names can be case-sensitive on Linux, so changing them can break a query. Leave Identifiers on *Keep as written* unless you know your database ignores case.

Trailing commas put the comma at the end of each line; leading commas put it at the start of the next:

-- Trailing (this formatter's output)
SELECT
  id,
  email,
  created_at
FROM users

-- Leading
SELECT
    id
  , email
  , created_at
FROM users

Leading commas make it easy to comment out the last column and keep diffs to one line when you append one. Trailing commas read like ordinary prose and are what most formatters and style guides produce, so this tool uses them. Whichever you choose, never leave a comma before FROM: most databases reject it.

Treat each common table expression (WITH name AS (…)) like a small named query: the name and AS ( on one line, the body indented one level, the closing parenthesis back at the margin, and a comma before the next CTE. The final SELECT starts at the left margin so the reader can find the query's output immediately.

WITH
  paid AS (
    SELECT customer_id, sum(total) AS revenue
    FROM orders
    WHERE status = 'paid'
    GROUP BY customer_id
  )
SELECT c.name, p.revenue
FROM customers c
JOIN paid p ON p.customer_id = c.id

Subqueries follow the same rule: indent the inner query one level deeper than the clause that contains it. Short expressions such as IN (1, 2, 3) stay on one line; raise or lower Inline width under More options to control when they break.

The core of SQL is shared, but the details a formatter must understand are not. Choosing the right Dialect stops it from misreading a quote or a comment:

Even string concatenation differs: a || b in PostgreSQL, SQLite and BigQuery, CONCAT(a, b) in MySQL (where || means OR unless PIPES_AS_CONCAT is set) and a + b or CONCAT(a, b) in SQL Server (SQL Server 2025 and Azure SQL also accept ||). Standard SQL works for portable queries. If you see an "Unexpected" error on code that runs fine in your database, switching the dialect is the first thing to try.

Yes, when it is done on tokens rather than with a regular expression. The minifier here collapses whitespace only between tokens, so the inside of every string, quoted identifier and dollar-quoted body is untouched. Line comments are kept with their line break (otherwise -- note would swallow the rest of the query), or removed entirely with Strip comments. Optimizer hints such as /*+ INDEX(users) */ and MySQL conditional comments such as /*!50100 … */ are always kept, because they change how the query runs.

Minified SQL is handy for log lines, for embedding a query in a JSON or YAML config, or for comparing two queries that differ only in layout. For anything a person will read, format it instead.