SQL Formatter & Minifier — Pretty-Print Queries for 11 Dialects

Paste a one-line query and get it indented and readable — MySQL, PostgreSQL, SQL Server, Oracle, SQLite, BigQuery and more. Or squash it back to one line.

🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free

Format SQL into readable, consistently indented queries: keywords on their own lines, clauses aligned, subqueries and CASE expressions nested, joins laid out one per line. Pick the dialect so that dialect-specific syntax — backtick identifiers, TOP, LIMIT, :: casts, window functions — is parsed correctly, and choose UPPERCASE or lowercase keywords and your indent size.

The minify button does the reverse for logs and query strings: comments removed, whitespace collapsed, string literals untouched. Everything runs in your browser.

How to use SQL Formatter

  1. Paste the SQL — a single query, a whole script, or something copied out of a log with all the whitespace gone.
  2. Choose the dialect that matches your database; Standard SQL works for most simple queries.
  3. Format (or Ctrl+Enter). Adjust keyword case and indentation to your team's style.
  4. Copy the result, or Minify to get a one-liner.

Why a real parser, not find-and-replace

Putting a line break before every FROM and WHERE is easy and wrong: it breaks a string that contains the word "from", mangles a subquery inside a CASE, and cannot tell a function argument list from a join condition. This page uses the open-source sql-formatter library, which tokenises the query according to the chosen dialect's grammar before laying it out — so PostgreSQL's ::text casts, T-SQL's square-bracket identifiers, MySQL's backticks and BigQuery's backtick-quoted project paths all survive.

Choosing a dialect

  • MySQL / MariaDB — backtick identifiers, LIMIT, # comments.
  • PostgreSQL:: casts, dollar-quoted strings, RETURNING.
  • SQL Server (T-SQL)[brackets], TOP, GO batches.
  • Oracle PL/SQL(+) joins, PL/SQL blocks.
  • SQLite, BigQuery, Snowflake, Redshift, Spark — their own keywords and quoting.

If formatting fails with a parse error, the dialect is usually the reason — the query uses a construct the selected grammar does not know.

Minifying honestly

The minifier strips -- and /* */ comments (or keeps them as block comments if you ask), collapses runs of whitespace to one space outside quotes, and removes the spaces around commas and parentheses. It never touches the inside of a string literal, so WHERE name = 'a b' keeps its double space. It does not rename anything or change semantics — it is whitespace only.

Formatting is not linting

A formatted query is easier to read; it is not necessarily correct or fast. The tool does not check that tables exist, that a GROUP BY covers every non-aggregated column, or that an index will be used. For that, run EXPLAIN in your database. For JSON payloads that travel with your queries, see the JSON formatter; for regular expressions inside REGEXP clauses, the regex tester.

Frequently asked questions

Which dialect should I choose?

The one your database speaks. Standard SQL handles plain SELECT / INSERT / UPDATE queries; pick MySQL, PostgreSQL, T-SQL, PL/SQL, SQLite, BigQuery, Snowflake, Redshift or Spark when the query uses their specific syntax — backticks, :: casts, TOP, [brackets]. A parse error usually means the wrong dialect.

Does formatting change what the query does?

No. Only whitespace, line breaks and (if you choose) keyword case change. Identifiers, strings and numbers are untouched. Minifying is whitespace-only as well; comments are removed unless you keep them.

Can it format a whole script with many statements?

Yes. Statements are separated by semicolons and formatted one after another with a blank line between them. Very large scripts (tens of thousands of lines) may take a few seconds.

Why did minify keep the double space in my string?

Because it is inside quotes, and changing it would change the query's meaning. The minifier collapses whitespace only outside string literals and quoted identifiers.

Is my SQL sent anywhere?

No. The formatter library runs in your browser; queries containing table names, credentials in comments or customer data never leave your machine.