FormatterHQ

SQL Formatter & Beautifier

Beautify SQL queries for 20 dialects. Clauses on their own lines, indented column lists and subqueries, and keyword case of your choice.

Input SQL
Output SQL
Ready.

How to use the SQL Formatter

  1. Paste your SQL query or script into the Input editor, or use Sample, Upload file or Load URL.
  2. Pick the Dialect your database uses, a Keyword case (UPPERCASE, lowercase or Preserve) and an Indent.
  3. Press Format to beautify, or Minify to put the query on one compact line.
  4. Use Copy or Download above the output panel to take the formatted SQL with you.

A SQL formatter that knows your dialect

Queries copied from application logs, ORMs or monitoring tools usually arrive as one long line. This SQL formatter turns them into a readable layout: each clause on its own line, selected columns and conditions indented beneath it, subqueries and CTEs nested, and keywords in consistent case. It is built on the open-source sql-formatter library and supports 20 SQL dialects, because MySQL, PostgreSQL, SQL Server and the others each have syntax the rest do not.

Example

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.status='active' and o.total>100 group by u.id,u.name having count(o.id)>2 order by orders desc limit 20;
SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.status = 'active'
  AND o.total > 100
GROUP BY
  u.id,
  u.name
HAVING
  COUNT(o.id) > 2
ORDER BY
  orders DESC
LIMIT
  20;

Every clause starts a new line, each column is on its own line, AND begins a new line inside WHERE, and operators are spaced. Functions such as COUNT are uppercased along with keywords. String literals like 'active' are left as they are. One exception: in the BigQuery, Hive, Spark SQL and Couchbase N1QL dialects a doubled quote inside a string, as in 'it''s', is read as two strings and printed as 'it' 's', so check such literals after formatting.

Why the dialect matters

SQL dialects disagree on quoting, operators and parameters. Choosing the right one lets the formatter tokenize your query correctly:

DialectSyntax it understands
MySQL / MariaDB`backtick` identifiers, @var := value, ? placeholders
PostgreSQL:: casts, ->> JSON operators, $1 parameters, dollar-quoted strings
SQL Server (T-SQL)[bracketed names], TOP, @param
BigQuery`project.dataset.table`, SELECT * EXCEPT (...), STRUCT and ARRAY
Oracle PL/SQL:bind variables and Oracle keywords

The other dialects are SQLite, Snowflake, Amazon Redshift, IBM Db2 and Db2 for i, Apache Hive, Spark SQL, Trino / Presto, DuckDB, ClickHouse, SingleStoreDB, TiDB and Couchbase N1QL. If a query fails with "Parse error: Unexpected ...", the dialect is the first thing to check. For example, select total::numeric from t fails as Standard SQL but formats as PostgreSQL, and [Order ID] needs the SQL Server dialect.

For formatting conventions and a closer look at how the 20 dialects differ, read How to format SQL.

Options explained

  • Keyword case – UPPERCASE (default) is the most common convention because it separates SQL keywords from table and column names at a glance. lowercase is popular in dbt projects and some style guides. Preserve leaves each keyword as typed. The setting also applies to data types and function names. An unquoted column name that is also a keyword in the chosen dialect, such as key or type, is upper-cased like a keyword. With the ClickHouse dialect, function and type names keep the case you typed, but such column names (there also name) are still upper-cased, so choose Preserve for ClickHouse queries.
  • Indent – 2, 3, 4 or 8 spaces, or tabs, for clause contents and nested queries.
  • Minify – the second button strips comments and collapses the query onto one line, useful for embedding SQL in code or config.

Scripts with several statements are formatted one after another, separated by a blank line, so you can paste an entire migration or seed file.

What gets formatted

SELECT queries with joins, subqueries and WITH common table expressions; CASE expressions (each WHEN on its own line); window functions with OVER (PARTITION BY ...); INSERT, UPDATE and DELETE statements; and DDL such as CREATE TABLE with one column definition per line. Comments are kept.

Common errors and fixes

  • Unexpected token after a quote: an unterminated string. SQL escapes a quote inside a string by doubling it: 'it''s'.
  • Template placeholders like {{ ref("orders") }} (dbt) or #{id} (MyBatis) are not SQL and may fail to parse. Replace them with a placeholder name before formatting.
  • Procedural code: long stored procedures with vendor-specific control flow may not format perfectly; format the queries inside them individually.

A formatter does not execute or validate queries against your schema. To turn query results into other formats, see SQL to JSON, and to prepare text for a SQL string literal, SQL Escape. For compact output only, the SQL Minifier keeps optimizer hints. Your queries are formatted in the browser and never sent to a server.

Frequently asked questions

Which SQL dialect should I choose?
Pick the database the query runs on. Standard SQL works for simple queries, but dialect-specific syntax such as PostgreSQL :: casts, SQL Server [brackets] or MySQL variables only parses with the matching dialect.
Does the SQL formatter validate my query?
It checks that the query can be tokenized and parsed for the chosen dialect, which catches problems like unterminated strings. It does not check table or column names or run the query.
Should SQL keywords be uppercase?
Uppercase keywords are the most common convention and make queries easy to scan. Lowercase is also widely used, for example in many dbt style guides. Consistency within a project matters most.
Can I format multiple statements at once?
Yes. Statements separated by semicolons are formatted in order with a blank line between them.
Are comments preserved?
Yes, when formatting. The Minify button removes comments, except optimizer hints written as /*+ ... */ and MySQL /*! ... */ comments. A # comment is removed only when the MySQL, MariaDB, TiDB, SingleStoreDB or BigQuery dialect is selected.

Last updated October 3, 2026

Guides

Related tools