SQL Query Formatter — Free HTML CSS JS Snippet

A one-line SQL query with three joins and a handful of conditions is nearly unreadable, but most SQL formatting tools are either a paid IDE plugin or a website that requires uploading the query. This snippet formats real SQL entirely client-side using pattern-based clause detection — no server round trip, no query text ever transmitted.

Detecting clause boundaries without a full parser

Writing a complete SQL parser is a large undertaking, so splitOnMajorClauses() takes a pragmatic approach: it builds one regular expression alternation from a list of major clause keywords (SELECT, FROM, WHERE, LEFT JOIN, GROUP BY, and so on), sorted longest-first so a phrase like GROUP BY matches before a bare BY could be mistaken for something else. Scanning the query for these keyword boundaries and slicing the text between consecutive matches reliably reconstructs each clause's text — the technique real formatting tools use before falling back to a full grammar for edge cases.

Splitting comma-separated lists without breaking on commas inside function calls

The naive way to split a SELECT list on commas breaks the moment a column expression contains a function call like COUNT(o.id, o.status) — a plain split(',') would cut the two function arguments into separate columns. splitTopLevelCommas() instead walks the text character by character, tracking parenthesis depth, and only treats a comma as a list separator when depth === 0. This is a genuinely correct approach — no comma inside any level of nested parentheses is ever mistaken for a top-level column separator.

Formatting SELECT, GROUP BY, ORDER BY and SET as vertical lists

Once a clause's items are correctly split, list-style clauses render one item per line, indented two spaces, which is how most style guides format anything beyond two or three selected columns. A "Leading commas" toggle switches between trailing-comma style (col1, then col2) and leading-comma style (col1 then , col2) — a genuine, actively-debated SQL style choice, included because different teams and style guides disagree on which is more readable and easier to diff in version control.

Keyword casing is a separate, reversible transform

The "Uppercase keywords" button runs an independent uppercaseKeywords() pass over the raw input before formatting, replacing every recognized keyword (again matched longest-first, so GROUP BY is replaced as a unit rather than GROUP and BY separately) with its uppercase form. Keeping this as a separate transform from clause splitting means a user who prefers lowercase keywords can format without ever triggering the case change.

Highlighting reuses the same keyword list

Rather than a separate token classifier, highlightKeywords() runs the identical KEYWORDS list used for uppercasing against the already-formatted text and wraps each match in a <span class="kw">, so the highlighted keywords in the output are guaranteed to be exactly the same set the formatter itself understands — there is no drift between what gets colored and what gets recognized as a clause.