SQL formatter/uppercase indent automatic formatting tool | ZeroTools

The SQL formatter and minifier tool provides two distinct text transformation operations for relational database query strings pasted into the text area interface.

The Format operation inserts line breaks and indentation spaces based on recognized keywords and punctuation, intending to improve the visual structure of the query for peer reviews, documentation, or manual debugging.

The Minify operation collapses consecutive whitespace and removes standard SQL comments, yielding a shorter continuous string intended for embedding within application source code, configuration files, or network payloads.

Users begin the process by pasting a raw SQL string, such as a continuous unformatted line like SELECT id, name, email FROM users WHERE status = 'active' AND age > 20 ORDER BY created_at DESC, into the primary input area.

By selecting either the Format or Minify button, the browser's local JavaScript runtime immediately executes the chosen transformation logic.

The processing is performed only using JavaScript in the browser and is not sent to an external server. You must independently verify the resulting SQL before execution.

The tool operates purely through sequential string replacement and regular expression matching techniques rather than deep structural analysis.

It utilizes temporary string placeholders to protect literal strings surrounded by single quotes, double quotes, or backticks. When the Format operation is selected, it additionally protects text residing within standard block comments and double hyphen line comments.

It is crucial to understand that this tool does not contain an abstract syntax tree parser, does not establish a connection to any database engine, and performs no syntax validation, dialect checking, automatic recalculation, or semantic verification on the input string.

The transformation applies generic layout rules without understanding the actual database dialect. Therefore, it cannot guarantee the execution correctness or semantic equivalence of the resulting formatted or minified query.

It is a misconception to assume that the absence of a query optimization engine means the logical execution path will remain completely unaltered.

On the contrary, these purely text-based transformations can easily change the underlying SQL meaning if not carefully reviewed. The tool explicitly provides no intentional plan optimization, and semantic equivalence is absolutely not guaranteed under any circumstances, meaning the developer assumes full responsibility for evaluating the final generated output string before any operational deployment.

To prevent the subsequent formatting rules from inadvertently modifying the contents of certain literal values, the tool employs a preliminary extraction and substitution phase.

When the user initiates a Format action, the JavaScript logic first scans the input text using simple regular expressions to locate string literals enclosed in single quotes, double quotes, or backtick characters.

Each matched literal is extracted and temporarily stored in a local dictionary, while the original text in the query is replaced with a sequentially numbered placeholder token.

For the Format operation, the script then performs a similar extraction for multi-line block comments enclosed within slash and asterisk markers, as well as single-line comments beginning with a double hyphen, substituting these annotations with placeholder tokens as well.

Conversely, when the Minify action is triggered, the tool protects only string literals using placeholders; it directly removes recognized standard comments without ever storing or restoring comment placeholders.

By substituting these arbitrary user inputs with predictable alphanumeric placeholders, the tool attempts a best-effort approach to prevent the subsequent tokenization, uppercase conversion, and spacing adjustments from altering the protected strings and annotations.

However, this protection does not strictly ensure that no internal whitespace is altered, because regular expression boundaries and final line trim operations can sometimes affect multiline literals.

Once the main structural formatting or minification logic has concluded, the tool performs a reverse substitution, scanning the transformed output string for the placeholder tokens and replacing them with the original protected content stored in the dictionary.

While this mechanism protects standard literal formats, it relies entirely on regular expression matching and lacks the contextual awareness of a true parser.

Consequently, a significant caveat is that placeholder token collisions can occur if the user's original query text already contains sequences resembling the internal placeholder format, leading to corrupted text replacement without any semantic guarantee.

Nested quotes or dialect-specific escape sequences may also not be accurately captured by the regex patterns, leaving portions of the string exposed to unintended formatting alterations and unexpected structural shifts.

After the string literals and standard comments have been safely replaced with placeholder tokens, the tool prepares the query for structural layout by isolating individual syntactic components.

The script standardizes the spacing around parentheses and commas, forcing spaces before and after these delimiters. It then splits the entire cleaned query string into an array of individual raw tokens using whitespace as the delimiter.

Because relational database query languages frequently utilize multi-word clauses that function as single logical commands, the script iterates through the raw token array to recombine specific recognized sequences.

For example, when the script detects the token GROUP immediately followed by the token BY, it merges them back into the single structural token GROUP BY.

Similar recombination logic is applied to other common multi-word keywords, including ORDER BY, INSERT INTO, DELETE FROM, LEFT JOIN, RIGHT JOIN, INNER JOIN, OUTER JOIN, CROSS JOIN, UNION ALL, CREATE TABLE, DROP TABLE, and ALTER TABLE.

By treating these merged phrases as single tokens, the subsequent layout engine can apply line breaks and indentation rules to the entire clause as a unified element, preventing inappropriate line breaks from occurring between the constituent words of the keyword phrase.

Any tokens that do not match these predefined multi-word combinations are passed to the layout engine as individual independent tokens, which are then evaluated against the keyword casing rules and output formatting directives without further grouping.

The formatting layout engine iterates through the tokenized query to construct the final text structure, applying user-defined preferences for indentation width and keyword capitalization.

Through the user interface controls, users can instruct the script to force recognized keywords into an uppercase format, a lowercase format, or to simply preserve their original casing as they were typed.

The tool checks each identified token against an internal set of recognized standard SQL keywords, such as SELECT, FROM, WHERE, and HAVING.

If a match is found and the uppercase option is selected, a lowercase select token is output as SELECT, while unrecognized tokens representing table names, column identifiers, or user variables remain in their original case since the tool does not implement a complete SQL grammar.

A plain, standalone JOIN keyword is recased according to these user settings, but it is not included in the specific list of structural keywords that automatically trigger newlines.

Instead, combined keyword clauses such as LEFT JOIN, RIGHT JOIN, INNER JOIN, OUTER JOIN, and CROSS JOIN are explicitly recognized as structural anchors that do trigger newlines at the current indentation depth to clearly delineate the major sections of the query.

The tool also provides straightforward UI options to select either a two-space or four-space indentation width. As the output string is constructed, indentation adjustments are based solely on parentheses.

Opening parentheses signal the start of a nested structure, such as a subquery or a function argument list, increasing the indentation level for all subsequent lines by the chosen two or four spaces.

Closing parentheses correspondingly decrease the indentation level. Commas also induce line breaks and indentation, ensuring that multiple selected columns in a SELECT list or multiple conditions in an IN clause are aligned vertically for easier visual scanning.

When the Minify compression operation is activated, the tool applies a strictly reductive set of transformation rules aimed at yielding a shorter continuous string representation of the SQL query.

As previously noted, the minify logic protects string literals by extracting them into temporary placeholders, but it directly strips out recognized block comments and double hyphen line comments without any initial comment-placeholder extraction phase.

The script then targets the whitespace throughout the query, converting all remaining line breaks, carriage returns, tabs, and consecutive spaces into single spaces.

To further reduce the string length, the script utilizes regular expressions to eliminate the spaces surrounding structural delimiters and mathematical operators.

It removes whitespace before and after commas, opening and closing parentheses, equal signs, and comparison operators. The script also aggressively attempts to collapse spaces around addition and subtraction operators.

Once the spacing reduction is complete, the original string literals are restored from their placeholders. There is no output minimality guarantee, meaning the final string might not represent the absolute shortest possible byte count for the given query.

More importantly, this minification process operates entirely on text patterns without any syntactic validation or understanding of the underlying database engine.

This aggressive spacing removal can easily introduce critical semantic dangers by inadvertently merging adjacent operator characters.

A verified example of this failure involves the query 'select 1 - -2'; the minify logic removes the space between the two negative signs, transforming the output into 'select 1--2', which effectively creates a standard double-hyphen comment and unintentionally comments out the remainder of the query in the target database.

Because the tool relies on a generalized regular expression engine rather than a sophisticated dialect-specific grammar parser, it cannot comprehensively protect all forms of valid database syntax from unintended modifications.

The string protection mechanism only recognizes standard single quotes, double quotes, and backticks; it does not protect PostgreSQL dollar-quoted string literals or strings containing complex escaped doubled quotes.

Unprotected string content will be incorrectly tokenized by the engine, resulting in unwanted uppercase conversion, collapsing of internal spaces, or line breaks inserted directly within the literal text.

The token substitution process itself poses a serious risk, as token placeholder collisions can occur if the source query naturally includes text matching the internal placeholder numbering scheme, thereby destroying the original content when the reverse substitution phase executes.

Furthermore, the layout adjustments can severely affect multiline string literals if standard line trim operations are inadvertently applied to lines that happen to fall inside a protected block, altering the exact spacing required by the developer.

It is crucial to dispel any promise or assumption that parsing the output ensures the execution plan or semantic meaning remains completely unaltered.

Due to these limitations, the text output generated by the Format or Minify operations must never be trusted implicitly. Users must manually inspect the resulting text diff to verify the precise character changes.

You should always use a dialect-specific parser and intended test fixtures to evaluate the modified query, and absolutely do not execute untrusted SQL directly against any production database system without verifying that no semantic shift has occurred.

There is simply no universal semantics guarantee provided by this strictly text-based manipulation utility.