Sql Formatter

Unlike JSON which has one strict universal standard, SQL is heavily fragmented into dozens of different "dialects" (PostgreSQL, MySQL, SQLite, T-SQL, etc.).

Formatting SQL accurately requires understanding the specific grammar of that dialect. For example, some dialects use double quotes " for strings, while others use them strictly for identifiers (table names). A formatter must know the dialect to avoid corrupting the query logic.

Before any formatting happens, the raw query string is passed through a Lexer, which breaks it down into an array of discrete tokens.

For example, SELECT * FROM users; becomes an array: ["SELECT", "Whitespace", "*", "Whitespace", "FROM", "Whitespace", "users", "Punctuation"].

The formatter then iterates through these tokens, discarding the original whitespace entirely. When it encounters a SELECT token, it knows the subsequent columns should be indented. When it hits a FROM or WHERE token, it triggers a new line and outdents. This state-machine approach ensures perfectly aligned queries regardless of how messy the original input was.

A SQL formatter is not a SQL validator. Because formatters usually rely on regex-based tokenizers rather than building a full Abstract Syntax Tree (which would be prohibitively slow and complex for every dialect in the browser), they will happily format completely invalid SQL (like SELECT FROM WHERE WHERE;).