FAQ
Which dialects are supported?
Mainly MySQL and Oracle common syntax; standard SQL generally formats correctly.
Can keywords be case-normalised?
There are two settings only: keep as written, or UPPERCASE. There is no lowercase option — paste already-lowercase SQL and keep it as written if that is your style.
Is text inside strings modified?
No. Strings and comments are preserved as a whole, so a select inside a string is not treated as a keyword.
About this tool
Formatting works at clause level: SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT, SET and VALUES each start a line, the SELECT list puts one column per line, AND / OR get an extra indent, and comparison operators are padded with spaces. Nested subqueries indent by bracket depth.
Recognition is driven by an explicit keyword table: main statements (including INSERT INTO, DELETE FROM, CREATE TABLE), join words (INNER / LEFT / RIGHT / FULL OUTER / CROSS JOIN) and condition words (ON, CASE, BETWEEN, IN, EXISTS, IS NULL…). Words outside the table are neither re-cased nor used to break lines — vendor functions and dialect extensions pass through unchanged.
Strings, backtick identifiers and comments are kept intact: `user` is not split apart, 'a, b' stays 'a, b' after minifying, and -- / /* */ comments survive beautify but are dropped by minify. Backticks are treated as MySQL identifier quotes, including the doubled-backtick escape.
Two limits: case handling has two settings only, keep as written or uppercase — there is no lowercase. And it is not a SQL parser: window functions like OVER (PARTITION BY …), multi-branch CASE WHEN and CTEs are laid out mechanically by brackets and keywords rather than intelligently. MySQL # line comments are not recognised (that character is needed for #tmp style table names). Minifying only removes whitespace and comments — not aggressively short, but semantics-preserving.