Jedes wichtige Klausel-Schlüsselwort wird in eine eigene Zeile gesetzt und großgeschrieben, wodurch aus einer Abfrage in einer langen Zeile etwas mit sichtbarer Struktur wird. Zu sehen, wo SELECT endet und WHERE beginnt, macht den größten Teil dessen aus, was eine lange Abfrage lesbar hält — und diese Änderung kostet nichts.
Es ist ein leichtgewichtiger Formatierer, und über seine Grenzen sollte man deutlich sein: Klauselinhalte werden nicht eingerückt, Joins nicht ausgerichtet, und verschachtelte Unterabfragen nicht anders gesetzt als die Abfrage darum herum. Schlüsselwörter werden überall erkannt, wo sie auftauchen, eine Spalte oder Tabelle mit einem solchen Namen — eine Spalte namens ORDER, ein Wert mit dem Wort FROM — wandert also ebenfalls in eine eigene Zeile.
Was es tut und wo es aufhört
-
Nur Klausel-Schlüsselwörter werden verschoben:
Alles dazwischen bleibt in einer Zeile, wie lang sie auch ist. Ein SELECT mit dreißig Spalten bleibt eine einzige lange Zeile.
-
Schlüsselwörter werden überall erkannt:
auch innerhalb von Zeichenketten in Anführungszeichen und in Bezeichnern, die zufällig reservierte Wörter sind — der eine Fall, in dem die Ausgabe mit dem Auge geprüft werden sollte.
-
Nichts wird geprüft oder ausgeführt:
Die Abfrage wird als Text behandelt. Syntaxfehler gehen unverändert hindurch, und hier besteht keine Verbindung zu einer Datenbank.
-
Der Dialekt bleibt unberücksichtigt:
Die Schlüsselwortliste ist der gemeinsame Kern. Konstrukte speziell für PostgreSQL, SQL Server oder Oracle bleiben, wo sie sind.
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.