SQL Formatter

Format or minify SQL with dialect-aware pretty-printing.

Dialect

Keywords

Indent

Mode

Upload .sql file

SQL Input

Output

How SQL Formatter works

This tool uses the sql-formatterlibrary — the category-standard engine behind VS Code SQL extensions and database IDEs — to parse and re-emit SQL with proper indentation, line breaks before each major clause, and consistent keyword casing. Choose from 9 dialects (Standard SQL, MySQL, PostgreSQL, T-SQL, SQLite, BigQuery, PL/SQL, MariaDB, Snowflake) for dialect-aware formatting. Keyword case options (UPPER, lower, preserve) let you match your team's style guide. Minify mode strips comments and collapses whitespace into a compact single-line query — useful for embedding in config files or query strings. Upload a .sql file or paste a query, then download the result. Everything runs locally in your browser — your queries never leave your device.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Making a generated query from an ORM readable enough to see which join is duplicating rows.
Normalising keyword casing across a migration file before review.
Breaking a long query out of one line so you can reason about its clause order.
Preparing a query for a ticket so a reviewer can follow it.
Comparing two similar queries by formatting both identically first.

How it works in practice

A worked example

An ORM has emitted a single-line query that is duplicating rows, and you need to see the clause order before you can work out which join is at fault.

Input

select u.id,u.name,count(o.id) as n from users u left join orders o on o.user_id=u.id where u.created_at>='2026-01-01' group by u.id,u.name having count(o.id)>3 order by n desc limit 10

Output

SELECT
  u.id,
  u.name,
  count(o.id) AS n
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.name
HAVING
  count(o.id) > 3
ORDER BY
  n DESC
LIMIT
  10

Same query, same plan, seven clauses you can now see one at a time. Each keyword takes its own line with its arguments indented beneath it, which is what makes the shape legible rather than the text shorter — and the two-line FROM block is where a duplication like this lives, because the join condition now sits directly under the join that owns it. Comments make the trip intact: a leading double-dash line stays where it was, and a slash-star comment mid-clause is moved onto a line of its own rather than dropped.

The edge case that catches people

The dialect selector is doing more than cosmetics, and the extra work is free. Backtick-quoted identifiers are a MySQL extension, so a query using them formats cleanly under the default and under MySQL, and is flatly rejected under PostgreSQL with a parse error naming the offending token and its position. That is not the tool failing. Set the dialect to the database you actually deploy against and a parse error here tells you the statement would not have run there either, which is a portability check nobody had to write.

When not to use this tool

Not across a repository you already have. Reformatting a few hundred existing migration files produces a whitespace-only diff that buries every real change in the same commit, and a reviewer has no way to separate them — the moment to format a query is when you write it, not two years afterwards. It is also a lexer and not a planner: it can tell you a statement is well-formed for a dialect and nothing whatever about whether it will be fast, so something that reads beautifully afterwards may still need an index before it is worth shipping.

Frequently Asked Questions

Which SQL dialects does this formatter support?: It handles standard SQL keywords (SELECT, INSERT, UPDATE, DELETE, CREATE, JOIN, etc.) and works with MySQL, PostgreSQL, SQLite, and SQL Server syntax. Dialect-specific functions are preserved as-is.
Does formatting change my query's behavior?: No. SQL is whitespace-insensitive — the database engine ignores formatting when parsing a query. Formatted SQL is functionally identical to a single-line version.
Is my SQL safe to paste here?: Yes. The tool runs entirely in your browser; your query is never sent to a server. You can safely format queries containing sensitive table names, column values, or business logic.
Why are SQL keywords uppercased?: Uppercasing keywords (SELECT, WHERE, JOIN) is the most widely-followed SQL convention. It visually separates keywords from identifiers (table/column names), making queries easier to scan at a glance.
Can it format stored procedures and multi-statement SQL?: Yes. Paste multiple statements separated by semicolons and each is formatted independently. Stored procedure bodies with BEGIN...END blocks and subqueries are also supported.
Why do formatters disagree about where to break a JOIN?: Because there is no standard — leading commas, right-aligned keywords and river formatting all have advocates. What matters is that one style is applied consistently, since diff noise costs more than any style's advantage.

Common errors and gotchas

Assuming the formatter validates. It arranges text and will happily format a query the database will reject.
Reformatting a query with a string literal containing SQL keywords, which some formatters treat as code.
Losing a dialect-specific construct that the formatter does not recognise and reflows incorrectly.
Treating uppercase keywords as a correctness matter rather than a convention.
Formatting a query built by string concatenation in code and pasting the result back, placeholders and all.