SQL Formatter

How to use the SQL Formatter

1. Paste a query, open a .sql file, or click Load sample.
2. Choose the dialect that matches your database so its special syntax is parsed correctly.
3. Pick the keyword case, indentation, layout and where AND and OR go. The result updates instantly.
4. Click Minify to one line if you need a compact query, then copy or download the result.

Features

• 20 SQL dialects, including MySQL, PostgreSQL, SQL Server, Oracle and BigQuery
• Uppercase, lowercase or unchanged keywords
• Spaces or tabs, with standard or tabular layouts
• Minify to one line while strings and identifiers stay intact
• Parse errors reported with line and column
• Formats several statements in one go

Why format SQL?

SQL is often written in a hurry and read many times. Queries copied from an ORM log, a monitoring tool or a colleague’s message tend to arrive as one long line, which makes it hard to see which conditions belong to which join or where a subquery ends. Consistent formatting puts each clause on its own line and indents what belongs to it, so you can review the logic, spot a missing join condition and get clean diffs when the query lives in version control.

A readable SQL style

Most style guides agree on a few habits, and the formatter applies them for you:

• Each major clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY) starts a new line.
• Selected columns and conditions are indented under their clause, one per line.
• Joins line up with the table they join to, with their ON condition on the same line.
• AND and OR start their lines, so you can comment one out or scan the conditions down the left edge.

SELECT
  c.region,
  SUM(o.total) AS revenue
FROM
  orders o
  JOIN customers c ON c.id = o.customer_id
WHERE
  o.status = 'paid'
  AND c.active = TRUE
GROUP BY
  c.region;

Uppercase or lowercase keywords?

SQL keywords are case-insensitive in every major database, so SELECT and select run the same way. Uppercase keywords stand out from table and column names, which is why many teams prefer them, while others find lowercase calmer to read. The keyword case option changes keywords only; your identifiers, string literals and comments keep their exact spelling, which matters because some databases treat quoted identifiers as case-sensitive.

Why the dialect matters

Every database adds its own syntax on top of standard SQL, and the formatter needs to know which rules apply in order to parse the query correctly:

If you see a parse error, the most common reason is syntax from another dialect, so switch the dialect first.

Minifying SQL

Minify to one line collapses all whitespace and removes comments, which is handy when a query has to fit into a string in application code, a configuration value or a log line. Because a -- comment would swallow everything after it on a single line, ticking Keep comments rewrites those as /* … */ instead. String literals and quoted identifiers are copied exactly, and optimizer hints (/*+ … */) and MySQL’s executable comments (/*! … */) are always kept because they change how the query runs.

Formatting is not validation

The formatter understands the structure of a query, not your schema. It cannot tell whether a table or column exists, and a query that formats cleanly can still fail when it runs. Test changes against your database, and use EXPLAIN to check how a query will execute. Formatting data rather than queries? Try the JSON Formatter or turn query results into JSON with the CSV to JSON converter.

Frequently asked questions