SQL Query Formatter & Minifier

Format messy SQL, or minify it to one line

Queries from an ORM log, a slow query report or an old script often arrive as a single dense line. This formatter puts each clause on its own line and indents joins and subqueries, so you can follow what a query does and find mistakes. It supports Standard SQL, MySQL, MariaDB, PostgreSQL, SQL Server, Oracle PL/SQL, SQLite and BigQuery. Select your dialect, so its specific syntax is handled properly.

Formatting only changes the layout. The query means the same thing and returns the same rows, and your SQL stays in your browser. Choose Minify to go the other way and turn a long query into a single line, which is handy for logs, config files, shell scripts and code strings. Text inside quotes is never changed. Comments are removed, except optimizer hints such as /*+ ... */, which affect how the query runs.

Example

A one-line report query before and after formatting, with keywords in uppercase and an indent of 2 spaces.

select u.id, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.active = 1 group by u.id;

SELECT
  u.id,
  count(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.active = 1
GROUP BY
  u.id;

Options

• Dialect: choose your database so that quoting styles and special operators are read correctly. For instance, MySQL uses backticks, while SQL Server uses square brackets.
• Keywords: use UPPERCASE, lowercase, or keep them as typed. Uppercase is the common convention, and makes the query structure stand out.
• Indent: choose 2 spaces, 4 spaces or tabs to match your project's style.

Reading a query once it is formatted

Consider how a query actually runs, which is different from how it is written. The database starts with FROM and JOIN, filters with WHERE, groups rows, filters groups with HAVING, then evaluates SELECT, and finally applies ORDER BY and LIMIT. This explains why a column alias defined in SELECT usually cannot be used in WHERE. Clean formatting also makes a few common bugs easier to spot:

• A LEFT JOIN condition placed in WHERE, which quietly turns it into an inner join.
• A missing ON condition, which multiplies rows.
• Mixed AND and OR without brackets, which may not group as you intended.
• SELECT * in application code, which returns columns you do not need.

Frequently Asked Questions

Does the formatter fix or validate my SQL?

No. It formats the text and only reports errors when it cannot parse the query. A nicely formatted query may still be wrong, so test it against your database.

Why do I get a parse error?

The query may use syntax from a different database. Check the Dialect option, then look for unbalanced quotes or brackets near the reported position.

Can I format several statements at once?

Yes. Separate them with semicolons, and each one is formatted with a blank line between them.

Is it safe to minify SQL?

Yes. Only whitespace and comments outside quoted text are removed, so the query returns the same result. Keep a formatted copy if you plan to edit it later.

Can I use placeholders?

Support varies by dialect. MySQL mode accepts ? but reports a parse error on :id, for example. If a placeholder is rejected, try another dialect or swap in a sample value while formatting.