Skip to content
koducathome

SQL Formatter

Format SQL queries for PostgreSQL, MySQL, SQLite, SQL Server, BigQuery and more, with configurable keyword case and indentation.

How to use this tool

Steps for using the SQL Formatter.

  1. Paste one or more SQL statements into Input SQL, or click Sample to load a query with joins and a GROUP BY.
  2. Pick the Dialect that matches your database — it decides which keywords, quoting styles and parameter placeholders are recognised.
  3. Choose keyword case (UPPERCASE, lowercase or preserve), indentation (2 spaces, 4 spaces or tabs) and how many blank lines separate statements.
  4. Click Format to beautify the SQL, or Minify to collapse it onto as few lines as possible. Tick Remove comments when minifying to strip comments as well.
  5. If the formatter cannot parse the SQL, read the error for the line and column, check quotes and parentheses, or try another dialect. Then copy or download the result.

Example

Format a one-line query (Standard SQL, uppercase, 2 spaces)

Input SQL
select id, name from users u join teams t on t.id = u.team_id where u.active = 1 and t.name like 'Eng%' order by name;
Formatted SQL
SELECT
  id,
  name
FROM
  users u
  JOIN teams t ON t.id = u.team_id
WHERE
  u.active = 1
  AND t.name LIKE 'Eng%'
ORDER BY
  name;

Common use cases

  • Making a long one-line query from application logs or an ORM readable before debugging it.
  • Normalising keyword case and indentation in SQL files before code review.
  • Preparing readable queries for documentation, tickets and pull requests.
  • Minifying a query to embed it in a string, a config file or a command-line call.
  • Checking whether a query is syntactically sensible for a given dialect.

How SQL formatting and minifying work

Formatting uses the open-source sql-formatter library, loaded on demand in your browser. It tokenises the query according to the selected dialect, then rebuilds it with each major clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY…) on its own line and the items under it indented. Only whitespace and keyword case change; identifiers, literals and comments are kept, so the formatted query means exactly the same thing.

Dialects matter because SQL syntax differs between databases. MySQL and MariaDB use backticks for identifiers and allow # comments, SQL Server uses [brackets] and @variables, PostgreSQL has $1 parameters, :: casts and dollar-quoted strings, and BigQuery uses backticks around project.dataset.table names. Formatting PostgreSQL-specific syntax as Standard SQL can fail or produce odd spacing, so pick the dialect your query targets. When the library cannot parse something it throws an error with a line and column, which the tool shows together with common causes.

Minify is implemented separately with a small scanner rather than the formatter, so it also works on SQL the formatter cannot parse. It walks the text and copies string literals ('…'), quoted identifiers ("…", backticks, and […] for T-SQL) and PostgreSQL dollar-quoted bodies byte-for-byte, collapses every other run of whitespace to a single space, and removes spaces next to (, ), , and ;, where that can never merge two tokens. Backslash escapes inside strings are honoured for MySQL, MariaDB, BigQuery and Spark, and for PostgreSQL E'…' strings.

Comments are kept by default. A -- line comment must end with a line break or it would swallow the rest of the query, so minified output keeps that newline. With Remove comments checked, --, # (MySQL-family dialects) and /* … */ comments are dropped — except MySQL executable comments /*! … */ and optimizer hints /*+ … */, which change how the query runs and are therefore preserved. Everything happens locally; your SQL is not uploaded.

Limitations

  • The formatter is not a database: a query that formats cleanly can still fail at runtime (unknown tables, type errors).
  • Stored procedures and vendor extensions are supported only as far as the sql-formatter dialect grammar covers them.
  • Minify does not validate SQL and only removes whitespace that is provably safe to remove; it does not shorten identifiers.
  • Input is limited to 2 million characters.

Frequently asked questions

Which dialect should I choose?

The one your query runs on. Standard SQL works for simple queries; choose PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery and so on when the query uses their quoting, parameter or function syntax.

Does formatting change what my query does?

No. Only whitespace and, if you choose, the case of SQL keywords change. Identifiers, string literals, numbers and comments are left as they are.

Why do I get a parse error for valid SQL?

Usually the dialect does not match — for example backtick identifiers in Standard SQL or $$ function bodies outside PostgreSQL. Unbalanced quotes or parentheses are the other common cause; the error shows the line and column where parsing stopped.

Is Minify safe for string contents?

Yes. Text inside quotes, quoted identifiers and dollar-quoted bodies is copied exactly, including repeated spaces and -- sequences. Only whitespace between tokens is collapsed.

Is my SQL sent to a server?

No. The formatter library is downloaded once and runs in your browser; queries are never uploaded or logged.