SQL Formatter & Minifier

SQL statements, especially ones written or generated in a hurry, are frequently either crammed onto one line (common in application code where a query string is built inline) or inconsistently cased and indented (common when a query has been edited by several people over time). Both make a query harder to read at a glance than it needs to be — a SELECT with several JOINs and a multi-condition WHERE clause is much easier to scan when each major clause starts its own line and keywords are visually distinct from column and table names via consistent capitalization. This tool takes a deliberately pragmatic, keyword-based approach rather than attempting to build a real SQL parser. A genuine SQL parser would need to understand a specific database dialect's full grammar (MySQL, PostgreSQL, SQL Server and Oracle all differ in meaningful ways — different quoting rules, different function sets, different proprietary syntax extensions), correctly handle arbitrarily nested subqueries, common table expressions (CTEs), window functions, and vendor-specific clauses, which is a substantial undertaking and inherently dialect-specific. Instead, this formatter recognises a broad set of common ANSI SQL keywords (SELECT, FROM, WHERE, INSERT INTO, UPDATE, DELETE, JOIN and its variants — INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN — ON, AND, OR, GROUP BY, ORDER BY, HAVING, LIMIT, UNION, and others), uppercases them for visual consistency, and places the major clause-starting keywords on their own line with indentation, while leaving everything else (identifiers, string literals, numbers, operators) exactly as written. The formatter is careful to avoid the most common way a naive find-and-replace keyword formatter breaks real queries: matching a keyword-like substring inside a quoted string literal or a quoted identifier. A query containing WHERE name = 'FROM the start' should not have "FROM" inside that string literal uppercased or treated as a clause boundary — this tool tracks whether it is currently inside a single-quoted string (with support for the standard SQL escaping convention of doubling a quote, '' , to represent a literal quote character within a string) and skips keyword matching entirely while inside one. Keyword matching is also done on whole-word boundaries, so a column literally named fromage or a table named ordering is not mistaken for the FROM or ORDER BY keywords. Because this is a textual, keyword-driven formatter rather than a parser that understands SQL's actual grammar and precedence rules, it does not track parenthesis nesting to intelligently indent deeply nested subqueries the way a true SQL-aware formatter would (a subquery inside a WHERE ... IN (SELECT ...) is formatted using the same flat clause-line rules as the outer query, rather than being indented as a nested block) — and it applies its keyword rules generically across ANSI SQL rather than tailoring output to any one specific database's dialect quirks or proprietary extensions. For a complex, deeply nested query or one using heavily vendor-specific syntax, the output may not look exactly the way a dedicated dialect-aware formatter (such as sql-formatter the npm package, or a database IDE's built-in formatter) would produce it, and you should sanity-check the formatted result before relying on it. For everyday queries — the kind most people actually paste into a formatter, a SELECT with a few JOINs and a WHERE clause — this approach produces clean, readable, correctly-cased output without needing a database connection or a dialect-specific parser.