Each major clause keyword is moved onto a line of its own and capitalised, which turns a query written as one long line into something with visible structure. Seeing where SELECT ends and WHERE begins is most of what makes a long query readable, and it is the change that costs nothing to apply.
It is a light formatter and it is worth being plain about the limits: clause bodies are not indented, joins are not aligned, and nested subqueries are laid out no differently from the query around them. Keywords are matched wherever they appear, so a column or table named after one — a column called ORDER, a value containing the word FROM — will be moved onto its own line too.
What it does and where it stops
-
Only clause keywords are moved:
everything between them stays on one line however long it is. A SELECT with thirty columns remains a single long line.
-
Keywords are matched anywhere:
including inside quoted strings and in identifiers that happen to be reserved words, which is the one case where the output needs checking by eye.
-
Nothing is validated or executed:
the query is treated as text. Syntax errors pass through untouched, and nothing here connects to a database.
-
Dialect is not considered:
the keyword list is the common core. Constructs specific to PostgreSQL, SQL Server or Oracle are left where they are.
What it actually does: one thing, done consistently
Each major clause keyword is moved onto a line of its own and capitalised, which is what turns a query written as one unbroken line into something with visible structure. Seeing exactly where `SELECT` ends and `WHERE` begins is most of what makes a long query readable at a glance, and the [msm_tool slug="sql-formatter"] exists specifically to make that one change reliably, without attempting anything more ambitious.
Clause bodies are not touched
Everything sitting between two clause keywords stays exactly as written, however long that stretch happens to be — a `SELECT` listing thirty columns remains a single long line rather than being broken up further or indented internally. This is a keyword-placement pass, not a full structural reformat.
Keywords are matched wherever they appear
Matching is not aware of quoted strings or identifiers, so a column genuinely named `ORDER`, or a text value that happens to contain the word `FROM`, gets moved onto its own line exactly as a real clause keyword would. That is the one situation worth checking by eye afterwards, since it is the case where the formatting can misfire on content that only coincidentally shares a word with SQL's own grammar.
Nothing is validated, parsed or run
The query is treated purely as text throughout. A syntax error passes straight through unchanged, and nothing here connects to an actual database at any point — formatting and correctness are two entirely separate questions, and this tool only ever answers the first one.
Dialect is not part of the picture
The keyword list covers the common core shared across SQL dialects, and anything specific to PostgreSQL, SQL Server or Oracle is left exactly where it was found rather than being reformatted incorrectly by a rule that does not actually understand it. Leaving a dialect-specific construct alone is the safer failure mode compared with guessing at how to format something it was never taught.