SQL formatter and beautifier

It reads your query token by token and prints it again with one rule set: every main clause (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) on its own line, the column list and conditions indented under it, AND and OR on new lines, and subqueries indented one more level. Short parenthesized expressions stay on one line; the Inline up to option sets how long they may be.

This one-line query:

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

comes out like this with the PostgreSQL dialect and uppercase keywords:

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

The River preset right-aligns the keywords into a column, the "river" that sqlstyle.guide describes, and puts commas at the start of each line:

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

Only whitespace and letter case change. Strings, quoted names and comments are copied as they are, so the formatted query returns the same rows. Several statements separated by semicolons are formatted one after another, with the blank lines you choose between them.

Databases quote names, mark parameters and write comments differently, and a formatter has to know which rules apply. Pick the wrong dialect and a valid query fails to parse. If you are not sure, leave it on Standard SQL: the tool points out syntax that belongs to a specific database and, on an error, lists the dialects that do parse your query.

The formatter does not run or validate your query against a schema. A clean format means the syntax is well formed for that dialect, not that the tables and columns exist.

This page uses sql-formatter, an open-source JavaScript library. You can call it from your own code with the same options:

import { format } from 'sql-formatter';

format('select id, name from users where id = 1', {
  language: 'postgresql',   // mysql, transactsql, bigquery, sqlite, ...
  keywordCase: 'upper',
  tabWidth: 2,
});

It also ships a command-line tool. --fix rewrites the file, and a .sql-formatter.json file in the project holds your settings, which makes it easy to run in a pre-commit hook or CI:

npx sql-formatter -l postgresql query.sql            # print the result
npx sql-formatter -l mysql --fix schema.sql             # rewrite the file in place
echo 'select * from t where id = 3' | npx sql-formatter # read from stdin

In Python, sqlparse formats SQL with options like keyword_case, reindent, strip_comments and comma_first:

import sqlparse

sql = "select id, name from users where id = 1"
print(sqlparse.format(sql, reindent=True, keyword_case="upper"))

For linting as well as formatting (naming rules, ambiguous joins, unused CTEs), teams often add SQLFluff. For one-off queries, the tool above is faster: paste, copy, done. Use Copy as on the output to get the SQL as a ready-to-paste string in JavaScript, Python, Go, Java, C# or PHP, escaped for that language.

It works the other way too. Paste SQL that is still wrapped in code, such as "select id " + "from users" from Java or JavaScript, a Python """...""" block or a C# @"..." string, and the tool reads the SQL out of the string literals before formatting it.

• Keyword case. Keywords are case-insensitive, so this is taste. Uppercase is the classic style and makes keywords stand out; lowercase reads more like code and is common in analytics teams. Leave function names and data types "as typed" unless your team has a rule.
• Trailing or leading commas. Trailing commas (a,) read naturally. Leading commas (, b) make it easy to comment out or add a column without touching the line above, and a missing comma is easy to spot. Both are fine; be consistent.
• AND first or last. AND at the start of the line lines up the conditions and makes each one easy to comment out. That is the default.
• Indent. Two spaces is the most common for SQL. Tabs work if your editor and code review tool agree on their width.
• Layout. Standard puts each clause keyword on its own line. The aligned layouts keep the keyword on the same line as its first item; River right-aligns keywords into a column.

Settings are saved in the page URL. Bookmark it, or send the link to your team, and everyone formats with the same style.

Switch to Minify to collapse a query onto one line: whitespace becomes single spaces, spaces around commas and parentheses go, and comments are removed. Strings keep their spacing. This is handy for log lines, JSON payloads, environment variables or a query string in a config file.

SELECT id,email FROM users WHERE active = true;

A -- comment would swallow the rest of a one-line query, so Keep comments rewrites them as /* */ comments instead. Minifying does not make a query run faster; the database ignores whitespace either way.

Need test rows to go with the query? The mock data generator writes SQL INSERT statements. Escape a value for a SQL string with the string escaper, compare two versions of a query in the diff checker, or tidy the JSON a query returns with the JSON formatter.