SQL Formatter and Beautifier

How to use the SQL formatter

1. Paste a query, a stored procedure or a whole migration script into the input box. Several statements separated by semicolons are fine.
2. Choose the dialect of your database. MySQL backtick identifiers, PostgreSQL :: casts and dollar-quoted bodies, SQL Server [bracket] names and BigQuery backtick table paths are only recognised when the matching dialect is selected.
3. Pick the keyword case and the indentation, then press Format (or Ctrl+Enter). Changing an option re-formats the current result.
4. Press Minify instead to collapse the query onto one line, then use Copy result.

Formatting is done by the open-source sql-formatter library, loaded from this site and running in your browser. Your queries are never sent anywhere, so it is safe to paste statements that contain table names, customer data or credentials.

Worked example

A query copied from application logs often arrives on one line:

select id, name from users where active = 1 and country in ('DE','AT') order by name;

With Standard SQL, uppercase keywords and 2-space indentation the result is:

SELECT
  id,
  name
FROM
  users
WHERE
  active = 1
  AND country IN ('DE', 'AT')
ORDER BY
  name;

Each clause starts a new line, every selected column gets its own line and boolean conditions are split at AND and OR. That layout makes diffs in code review much smaller: adding a column changes one line instead of the whole statement.

What formatting and minifying change

The formatter tokenizes the query according to the selected dialect, builds a syntax tree and prints it again. Only whitespace and, if you ask for it, the case of keywords change. String literals, quoted identifiers and comments are copied exactly, so 'Hello World' keeps its two spaces and "OrderDate" keeps its capitals.

Minify works on tokens as well. It collapses runs of spaces and line breaks outside strings and quoted identifiers and removes the space next to commas, parentheses and semicolons. Ordinary comments are removed, because a -- comment on a single line would otherwise swallow the rest of the query. MySQL executable comments (/*! ... */) and optimizer hints (/*+ ... */) are kept, since they change how the query runs.

Common mistakes

• Wrong dialect – a parse error on a backtick, a # comment or a $1 placeholder usually means the query is written for another database. Switch the dialect and format again.
• Unbalanced brackets or quotes – the status line shows the line and column where parsing stopped. A missing closing parenthesis is often reported at the end of the query.
• Placeholders from another database – parameter syntax depends on the dialect: ? for MySQL, $1 for PostgreSQL, @name for SQL Server and :name for Oracle. Template syntax such as {{ name }} is not SQL at all; replace it with a dummy value before formatting.
• Expecting validation – the formatter checks structure, not meaning. It does not know your schema, so a misspelled column name is formatted without complaint.

Formatting JSON returned by a query? Use the JSON formatter. To compare two versions of a long query, run both through this tool first and then put them into the text diff checker, so only real changes show up.