What the formatter does
Three things, consistently. Keywords are uppercased, so select becomes SELECT and left join becomes LEFT JOIN, while your table and column names keep their case. Each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, LIMIT and friends) starts a new line. And the connective tissue is indented: AND and OR conditions, JOIN conditions after ON, and each item in a comma-separated list get their own indented lines, so the shape of the query matches the shape of the logic.
Strings in single quotes, identifiers in double quotes, backticks or square brackets, numbers and both styles of comment are recognised and passed through untouched, so a WHERE clause comparing against 'John' does not come out shouting 'JOHN'. Everything runs in your browser and your queries are never uploaded anywhere, which matters when they contain live schema names and real customer values.
Worked example
The one-line original and the formatted version run identically; the only difference is that a human can now scan the columns, spot the filter conditions and see the sort order at a glance. This matters most in code review, where a query buried on one line is a query nobody actually reads.
Honest scope: a layout tool, not a parser
This formatter works from tokens, not from a full grammar of any SQL dialect, and that has consequences worth knowing. It does not validate your query, so typos survive formatting. An unquoted column that happens to share a name with a keyword, such as one called count or key, will be uppercased; quote it and it is left alone. Deeply nested subqueries are indented by bracket depth, which is readable but plainer than what a dialect-aware tool like a database IDE produces. And dialect-specific extensions pass through unformatted rather than causing errors. For a quick tidy of everyday queries, that trade is the right one; for enforcing a house style across a large codebase, use a formatter wired into your editor or CI.
Why consistent SQL layout matters
SQL is one of the few languages where a single statement routinely grows to dozens of lines of interlocking logic, and unlike most code, queries get passed around in chat messages, tickets and log files where formatting dies. Re-formatting on arrival is the cheap fix. Uppercase keywords act as visual anchors, one clause per line means a diff shows exactly which condition changed, and indented AND chains expose precedence mistakes, since an OR hiding among ANDs without brackets is the classic source of a query that returns ten times the rows it should. If a formatted query still will not run, the database's own error message plus a readable layout will get you to the problem line far faster than the one-line original ever would.
Frequently asked questions
Is my SQL uploaded anywhere?
No. Formatting runs entirely in your browser with JavaScript, so queries never leave your device. That makes it safe to tidy queries containing real table names, schema details and literal values from production systems.
Will formatting change what my query does?
No. The formatter only changes whitespace and the case of keywords. Quoted strings, quoted identifiers, numbers, comments and the order of every token are preserved, so the query means exactly what it meant before, just laid out readably.
Why are my column names not uppercased?
Only words on the formatter's keyword list are uppercased, so identifiers such as table and column names keep the case you wrote them in. A column that happens to be named like a keyword, for example one called count, will be uppercased too; quote such identifiers and they are left completely alone.
Which SQL dialects does this work with?
The layout rules cover the shared core of SELECT, INSERT, UPDATE and DELETE statements, which is common to PostgreSQL, MySQL, SQL Server, SQLite and most other dialects. Single quotes with doubled escapes, double-quoted and backtick-quoted identifiers, and both comment styles are all understood. Dialect-specific syntax passes through unformatted rather than breaking.
Does it validate my SQL?
No. It is a formatter, not a parser, so it will happily lay out a query with a typo in it. Syntax errors only surface when the database itself runs the query. For checking logic, formatting still helps, because a wrongly placed condition is far easier to spot at one clause per line.