A query copied from a log, an ORM debug dump, or a database admin console almost always shows up as one long line with no breaks at all. Reading SQL like that and spotting a bug in it is hard. A SQL formatter fixes this in a second.
What a formatter does
A formatter adds line breaks and indentation following standard conventions: each top-level keyword (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY) starts on its own line, the list of fields and conditions lines up in a column, and nested subqueries get extra indentation.
For example, a query like this:
select u.id, u.name, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.active = 1 group by u.id, u.name having count(o.id) > 0 order by orders desc limit 10;
becomes, after formatting:
SELECT
u.id,
u.name,
count(o.id) as orders
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.active = 1
GROUP BY
u.id,
u.name
HAVING
count(o.id) > 0
ORDER BY
orders DESC
LIMIT
10;
Supported dialects
SQL isn't quite one single language: MySQL, PostgreSQL, SQLite, MariaDB, T-SQL (SQL Server), and BigQuery each have their own syntax quirks (for example, TOP in T-SQL instead of LIMIT). The SQL formatter can take the selected dialect into account so constructs like that are recognized correctly instead of breaking the parser.
Keyword case
A separate setting controls keyword case: SELECT in uppercase or select in lowercase. This is a matter of team or project style with no single standard, so the tool lets you switch case with one click.
Why this matters
- Code review. A formatted query reads in seconds instead of requiring a line-by-line hunt for the WHERE clause.
- Performance debugging. Before figuring out why a query runs slowly, it helps to see its structure clearly first.
- Documentation and migrations. Neatly formatted SQL is easier to keep in a repository and compare via git diff.
Formatting runs entirely in the browser — the query is never sent anywhere, which matters if it contains real table names or conditions with sensitive data.