Skip to content
codevory

SQL Formatter

Format SQL queries for 12 dialects, with the keyword case and indentation you prefer. Comments are kept, and strings are never touched.

SQL Formatter: the tool

Paste SQL to format it.

Input

Formatted SQL

The result appears here.

How to use SQL Formatter

  1. Paste a query, or several statements separated by semicolons, or press Example.
  2. Choose the dialect that matches your database. It decides how quoted names, comments and dialect-specific operators are read.
  3. Pick keyword case (uppercase is the common convention), the indentation and the spacing between statements.
  4. Copy the result or download it as a .sql file. Comments are kept where they were.

Example

A one-line report query with a comment, formatted with uppercase keywords and 2 spaces. The comment stays on its line.

Input
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.active = true and o.created_at >= '2026-01-01' -- recent orders only
group by u.id, u.name having count(o.id) > 2 order by orders desc limit 10;
Output
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.active = TRUE
  AND o.created_at >= '2026-01-01' -- recent orders only
GROUP BY
  u.id,
  u.name
HAVING
  count(o.id) > 2
ORDER BY
  orders DESC
LIMIT
  10;

About this tool

A formatter changes only layout: it puts each clause on its own line, indents the columns and conditions under it, and writes keywords in the case you choose. The query keeps the same meaning, and a unit test checks that the sequence of tokens in the output equals the input apart from keyword case.

The dialect matters because SQL is not one language. PostgreSQL uses ::casts and $$ quoting, MySQL uses backticks and # comments, SQL Server uses [brackets] and #temp tables, and BigQuery and Snowflake add their own functions. Choosing the wrong one can make a valid query fail to format, and the error message says so. Standard SQL is a good starting point.

This tool reads the structure of a statement, but it does not run it or look at your schema, so it is a formatter and not a validator: it cannot tell you that a table does not exist or that a function is called with the wrong arguments. There is no reliable way to validate SQL in a browser without the database engine that will run it, so this site does not offer an SQL validator. An error from the formatter means the text cannot be read as SQL of the selected dialect, which is usually a sign of a real syntax mistake such as an unclosed quote.

Frequently asked questions

Does formatting change what my query does?

No. Only whitespace and the case of keywords change. Identifiers, strings, numbers and comments are kept as written, so the query returns the same result.

Is there an SQL validator?

No, on purpose. Whether a query is valid depends on the database that runs it: its dialect, its version, your tables and your permissions. A browser tool cannot know those, and a generic checker would give false errors and false approvals. The formatter reports text that cannot be read as SQL, and your database's own EXPLAIN or a dry run is the real test.

Why does my query fail to format?

Usually an unclosed quote or comment, a character that the selected dialect does not allow, or a dialect mismatch, such as MySQL backticks while Standard SQL is selected. The message gives the line and column of the first thing it could not read. Try the dialect of your database.

Should keywords be uppercase?

It is a convention, not a rule. Uppercase keywords make the structure of a query stand out from table and column names, and many style guides require them. Lowercase is also common in modern codebases. Choose what your team uses.

Are comments preserved?

Yes. Both -- line comments and /* block */ comments are kept next to the code they annotate.

Is my SQL uploaded?

No. Formatting happens in your browser, so queries that contain table names, customer data or credentials stay on your device.

More developer tools