How it works
A query written on a single line, copied from a log or generated by an ORM, is hard to read and to review in a pull request. This tool formats it: every clause (SELECT, FROM, WHERE, GROUP BY…) gets its own line, columns and conditions are indented, and multiple statements are separated by a blank line.
Pick your database dialect: PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino, DuckDB or ClickHouse. That way its own syntax, functions and identifier quoting are recognized. Keywords sets UPPERCASE, lowercase or as typed; indentation can be 2 or 4 spaces.
If the query has a syntax error, such as an unclosed quote or an extra parenthesis, you see the message with its line and column. Often the culprit is the dialect: a query that is valid in PostgreSQL may not be valid in standard SQL.
It is handy for reviewing slow queries, documenting migrations, preparing README examples or understanding what your ORM generates. Everything runs in your browser.
Examples
One-line query
select id, name from users where active = true order by id
SELECT id, name FROM users WHERE active = TRUE ORDER BY id
Several statements in lowercase
SELECT 1; SELECT 2;
select 1; select 2;
Frequently asked questions
Why does the dialect matter?
Every engine has its own syntax: backticks in MySQL, square brackets in SQL Server, operators like :: or ->> in PostgreSQL. Picking the right dialect avoids errors and keeps those constructs intact.
Does it change what the query returns?
No. Only whitespace, line breaks and, if you ask, keyword case change. Table and column names and quoted strings stay untouched.
Does it validate the query?
Partly: it catches syntax errors such as unclosed quotes or parentheses, but it does not check that tables or columns exist.
Can I paste queries with production data?
Yes. Formatting happens in your browser with the sql-formatter library and the query is never sent to a server.