I once reviewed a pull request where the entire database migration was one line. Four hundred and twelve characters of SQL, no line breaks, no indentation, a JOIN buried somewhere in the middle like a landmine. The query was correct. It also took me twenty minutes to be sure it was correct, because I could not read it.
That is the whole case for a SQL formatter. It does not make your query faster. It does not fix your logic. It makes the query readable enough that a human can spot the bug before it ships.
Formatting is not cosmetic
A formatter does two honest things. First, it puts one clause per line: SELECT, FROM, WHERE, GROUP BY, ORDER BY. Second, it indents the parts that belong together, so a JOIN condition sits under its JOIN and a subquery is visibly nested inside its parent. That is it. No magic, no rewriting. The formatted query does exactly what the original did, because only whitespace and casing changed.
The bug I was hunting in that PR turned out to be a missing condition in the WHERE clause. On one line, the WHERE clause looked like a wall of text and my eyes slid right past it. Formatted, the missing condition was obvious in about four seconds, because the list of conditions was vertical and one item was simply absent.
The dialect trap nobody warns you about
Here is where most people pick the wrong formatter: SQL is not one language. MySQL uses backticks for identifiers. SQL Server uses square brackets. PostgreSQL uses double quotes. BigQuery has its own ideas about everything. A formatter that does not know your dialect will happily "fix" syntax that was never broken, or choke on syntax that is perfectly valid in your database.
So the first question a good formatter asks is not "how many spaces" but "which database". Standard SQL, MySQL, PostgreSQL, SQLite, SQL Server, Oracle, BigQuery, Snowflake, Redshift: each one parses differently. If your formatter treats them all the same, it is guessing, and guessing with production queries is a bad habit.
Minify is the opposite direction, and it has a use
Formatting spreads a query out. Minifying crushes it into one line. That sounds like going backwards, until you need to paste a query into a URL parameter, a log line, or a config value where newlines are not welcome. Minify is a transport format, not a reading format. The rule is simple: format for humans, minify for machines, and never confuse the two.
One warning about minifying: a careless minifier will strip a comment that your query actually needs, or join two tokens that were only separated by whitespace. A good one leaves string literals and comments alone. If yours does not, find another one.
Your queries should never leave your browser
This matters more than people admit. The queries you format are often production queries. They contain real table names, real column names, sometimes real customer IDs baked into a WHERE clause. A formatter that uploads your SQL to a server to format it is a data leak wearing a tool costume.
The safe version runs entirely in your browser. Paste, format, copy, done. Nothing is uploaded, nothing is stored, nothing is logged. If a tool cannot promise that, do not paste production SQL into it. I built a free one that works exactly this way, with dialect selection, keyword casing, indentation options and a minify mode: it formats MySQL, PostgreSQL, SQLite, SQL Server, Oracle, BigQuery and more, all in your browser. You can try it here: https://www.theutilityhub.online/tools/sql-formatter
A small habit that pays off
Before you paste a query into a pull request, a migration file, or a chat message to a colleague, run it through a formatter. It takes three seconds. The person reading it, which is often future you, will be able to see the structure instead of decoding a wall of text. And the next time a WHERE condition goes missing, you will spot it in four seconds instead of twenty minutes.
