SQL Formatter

It works in four passes, and knowing them explains every line of the output:

1. All whitespace, line breaks included, collapses to single spaces.
2. Recognised keywords (SELECT, FROM, JOIN, AS, IN, NULL, DESC and about 40 others) are uppercased. Everything else keeps its case.
3. Major clauses start a new line: FROM, WHERE, the joins, GROUP BY, ORDER BY, HAVING, LIMIT, UNION, VALUES, SET and others.
4. Every comma is followed by a line break and two spaces of indent.

The built-in sample, a one-line query with a join and a group-by, comes out like this:

The formatter doesn't know where a quoted string starts and ends, so it reformats inside quotes too. This query:

comes back with the string itself changed: it now reads 'SELECT this,, then a line break, then FROM here'. The keywords inside it were uppercased, a line break and indent were added after the comma, and the triple space shrank to one. Run that and you are filtering on a different value. If your literals contain commas, keywords or repeated spaces, compare them with the original before executing.

Line comments are the other trap. Because all line breaks are removed first, a -- comment swallows whatever followed it. where a = 1 -- only active followed by and b = 2 on the next line becomes WHERE a = 1 -- only active AND b = 2, so the second condition is now part of the comment. Delete -- comments or turn them into /* … */ before formatting.

• Split joins: two-word joins break across lines, giving LEFT on one line and JOIN orders o … on the next. The same happens to INNER JOIN and DELETE FROM. The SQL still runs, but you may want to rejoin them by hand.
• Conditions stay inline: WHERE x = 1 OR y = 2 remains on one line. AND and OR are uppercased but not moved.
• Commas everywhere break: function arguments and IN lists split too, so IN ('a', 'b') spans two lines.
• Subqueries aren't indented: an inner SELECT gets the same left-edge layout as the outer query.
• Columns named like keywords: a column called end becomes END. Most databases treat unquoted names case-insensitively, but quoted identifiers in PostgreSQL are case-sensitive.

The formatter is at its best on the long single-line queries you copy out of application logs, ORM debug output or a slow-query report. Breaking them at each clause makes it quick to see which tables are joined, what the filter is and how the result is sorted. For queries you commit to a repository, a formatter that understands your SQL dialect and your team's style rules is a better fit than this quick reformatting.