SQL Formatter: Frequently Asked Questions

No. The formatter only changes whitespace, line breaks, and keyword casing. SQL is whitespace-insensitive and keyword-case-insensitive, so formatted and unformatted versions of the same query produce identical results when executed.

The formatter handles standard SQL syntax that is common across all major databases. Database-specific syntax extensions (MySQL's backtick identifiers, PostgreSQL's double-colon casting, SQL Server's square bracket identifiers) are preserved but may not be perfectly formatted in all cases.

Full SQL syntax validation requires parsing the query against a specific database dialect's grammar and verifying that referenced tables and columns exist. This requires a database connection. The formatter only applies structural formatting rules without parsing the full semantic meaning of the query.

Minification collapses SQL to a single line. Common uses: embedding SQL in JSON configuration files where multi-line strings are not supported, storing queries in database metadata fields, and transmitting SQL in APIs that expect single-line strings. Minified SQL runs identically to formatted SQL.

The formatter handles the SQL within stored procedures and functions, but procedural SQL extensions (BEGIN...END blocks, DECLARE statements, cursor logic, exception handling) may not format perfectly as they vary significantly between database dialects.

Both conventions are valid and it is a matter of team preference. UPPERCASE keywords are the traditional standard and make the query structure immediately visible by contrasting keywords against lowercase identifiers. Lowercase is preferred by some modern teams. The most important thing is consistency — pick one and stick to it.