How to format SQL
- Choose the dialect that matches your database. Standard SQL works for most simple queries.
- Paste your SQL into the Your SQL box. Pasting formats it straight away.
- Adjust the style options if you like; the result updates as you change them.
- Copy the result, or download it as a
.sqlfile.
If the formatter cannot understand part of the query, it says what it found and where, and Go to errorselects that spot in your SQL. Your input is never changed.
Why the dialect matters
Every database adds its own syntax on top of standard SQL, and the formatter needs to know which rules to follow. For example:
| Dialect | Syntax it understands |
|---|---|
| PostgreSQL | $1 placeholders, :: casts, ->> JSON operators, $$ function bodies |
| MySQL and MariaDB | `backtick` names, # comments, LIMIT |
| SQL Server | [bracketed names], @variables, TOP |
| BigQuery | `project.dataset.table` names, @parameters, triple-quoted strings |
| Snowflake | v:path access to semi-structured data, $$ strings |
Style options
- Keywords: make keywords such as
SELECTandWHEREuppercase or lowercase, or leave them as typed. Data types such asINTfollow the same choice. - Change function names and data types too: also applies the case to functions such as
COUNT(). - Indent: two spaces, four spaces or tabs.
- AND and OR: start each condition with
AND, or end the line with it. - Keep brackets on one line: a bracketed expression, such as a function call or an
INlist, stays on one line if it fits within this many characters. Otherwise it is split over several lines.
Minify
Minify puts the query on as few lines as possible, which is handy for pasting into code or a log. It only removes whitespace that has no meaning:
- Strings, quoted names and
$$bodies are copied exactly, including their spaces and line breaks. - Comments are removed if you choose, except optimiser hints (
/*+ … */) and MySQL’s/*! … */, which can change how a query runs. - A kept
--comment is followed by a line break, so it cannot hide the SQL after it.
Limitations
- The formatter checks that the query has a sensible structure, but it does not check it against your database. It can accept SQL that your database would reject, such as a misspelt table name.
- Procedural code, such as stored procedure bodies, PL/pgSQL inside
$$and T-SQL control-flow blocks, may be left as it is or formatted less neatly than plain queries. - Template languages such as dbt and Jinja are not supported.
- Input is limited to 500,000 characters. Very large scripts can take a few seconds.
- Formatting uses the open-source sql-formatterlibrary (MIT licence).
Frequently asked questions
Is my SQL sent anywhere?
No. The formatter runs in your browser. The first time you format, the page downloads the formatting code for your chosen dialect from this website, but your query never leaves your device. That makes it safe to tidy queries that mention real table names, customer data or credentials, although it is still good practice not to keep passwords in SQL files.
Will formatting change what my query does?
No. Formatting only changes whitespace and the case of keywords (and, if you ask, function names and data types). Table and column names, strings and numbers are never changed. Minify removes whitespace and, if you choose, comments; it always keeps optimiser hints such as /*+ INDEX(…) */, because they affect how a query runs.
Why does it say “Unexpected” when my query works in my database?
Each database adds its own syntax, such as [square brackets] in SQL Server, `backticks` in MySQL or $1 placeholders in PostgreSQL. Standard SQL does not include these, so choose the dialect that matches your database and format again. If it still fails, the formatter may not support that particular feature yet.
Can it format dbt or Jinja templates?
Not reliably. Template tags such as {{ ref('orders') }} and {% if %} are not SQL, so the formatter usually reports them as unexpected. Format the compiled SQL instead, or minify, which leaves anything it does not recognise alone.