SQL Formatter

What the formatter does

A one-line query from a log file or an ORM is hard to read. The formatter parses it into tokens and lays it out with one clause per line, one column or condition per line, and joins indented under FROM:

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 = 1
  AND o.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.email
HAVING
  count(o.id) > 5
ORDER BY
  orders DESC
LIMIT
  10

That output is the real result for the same query pasted as a single line with the MySQL dialect and uppercase keywords. Formatting changes only whitespace and keyword case. String literals, identifiers and function names keep their exact spelling, so the formatted query returns the same result as the original.

Choosing the dialect

SQL dialects differ in exactly the places a formatter must understand: how identifiers are quoted, which characters start parameters and comments, and which words are keywords. With the wrong dialect, a valid query can fail to format or be split in odd places.

MySQL / MariaDB     `backtick identifiers`, ? placeholders, # comments
PostgreSQL          "double-quoted identifiers", $1 parameters, :: casts, $$ strings
SQL Server (T-SQL)  [bracket identifiers], @variables, TOP instead of LIMIT
Oracle PL/SQL       :named binds, "QUOTED" identifiers
SQLite              accepts most of the above styles
BigQuery            `project.dataset.table` names

Standard SQL is a sensible default when you are not sure. If you get a parse error for a query that runs fine in your database, switch to that database's dialect before assuming the query is wrong.

Keyword case and indentation

Uppercase keywords (SELECT, FROM, WHERE) are the most common convention: they separate the query's structure from table and column names at a glance, and most SQL style guides use them. Lowercase is popular in teams that find uppercase noisy. The third option keeps keywords as you typed them, useful when you only want the layout fixed.

Choose 2 or 4 spaces to match your codebase. What matters more than the choice is consistency: run every query in a repository through the same formatter with the same settings, and diffs show real changes instead of whitespace noise. For code in a repository, the same engine is available as the sql-formatter npm package and command-line tool, and SQLFluff can both format and lint SQL in CI.

When formatting fails

The formatter tokenises the query according to the chosen dialect and reports where it cannot continue, for example Parse error: Unexpected "[x" at line 1 column 27. The usual causes are an unclosed quote or bracket, a dialect-specific construct used with another dialect, or a fragment rather than a full statement. The line and column point to where reading stopped, which is often just after the real mistake.

A formatter is not a validator. It does not check that tables or columns exist, that types match or that the query is logically correct; a query can format perfectly and still fail in the database. Run the formatted query, or use EXPLAIN, to check it.

Formatting queries from logs and ORMs

ORMs such as Hibernate, Eloquent, Django and Entity Framework log queries on one line with placeholders. Paste them to read the joins and conditions, then substitute the bound values by hand when you want to run the query. Keep placeholders as they are when sharing a query with colleagues: ?, $1, :id and @id are all recognised by the matching dialect and stay intact.

Slow query logs from MySQL and pg_stat_statements in PostgreSQL normalise literal values to placeholders, so the formatted query shows the shape of the problem query. From there, look at the WHERE and JOIN conditions to see which columns need an index.

Readable SQL beyond formatting

Formatting is the first step. Readable queries also use meaningful table aliases (orders o, not t2), explicit JOIN … ON instead of comma joins with conditions in WHERE, column lists instead of SELECT * in application code, and common table expressions (WITH …) to name intermediate steps of a long query. Put comments above the query or a CTE, and prefer -- line comments, which every dialect supports.

Frequently asked questions

How do I format a SQL query online?

Paste the query into the left box, pick your database dialect, and copy the formatted result from the right. Keyword case and indentation can be adjusted with the menus above.

Does formatting change what my query does?

No. Only whitespace and keyword case change; identifiers, strings, numbers and function names are kept exactly, so the query returns the same result.

Which SQL dialects are supported?

Standard SQL, MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), Oracle PL/SQL, SQLite, BigQuery, Snowflake and Redshift.

Why do I get a parse error?

Usually an unclosed quote or bracket, or syntax from another dialect, such as MySQL backtick identifiers with PostgreSQL selected, or PostgreSQL $1 parameters with SQL Server selected. Choose the dialect your database uses and check the reported line and column.

Does the formatter check if my SQL is valid?

No. It only checks that it can read the tokens. It does not know your schema, so run the query or use EXPLAIN to validate it.

Does pretty-printed SQL run slower?

No. The database parser ignores whitespace and keyword case, so the execution plan is the same. The exception is anything keyed on the exact query text, such as the MySQL query cache (removed in MySQL 8.0), which treats a reformatted query as a new one.