How it works
The formatter takes a minified or inconsistently written query and rewrites it with one clause per line, aligned conditions and consistent keyword casing. Major clauses — SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT, every JOIN variant — each start on their own line, while AND/OR conditions and ON clauses are indented beneath their parent clause. Comma-separated select lists are broken onto individual lines so wide projections stay readable.
String literals are protected before any keyword processing runs: text inside single or double quotes is extracted, the formatting is applied, and the strings are restored byte-for-byte. A keyword that happens to appear inside a string — 'where' in a label, for example — is never rewritten.
Keyword casing is a team preference, so both directions are offered: UPPERCASE for the classic style, lowercase for the modern one. Indent width is selectable between two and four spaces.
This is a deliberately lightweight, dialect-agnostic formatter. It handles the everyday SELECT/INSERT/UPDATE/DELETE workload — joins, nested expressions, grouping, ordering — but it is not a full SQL parser: vendor-specific syntax such as T-SQL bracket identifiers or PL/SQL blocks is normalized conservatively rather than deeply understood. For those, use a dialect-aware tool such as sqlfluff.
Worked example
Format a typical reporting query written on one line: joins, a filter, grouping and a limit.
| Before | After |
|---|---|
select u.id,u.email,count(o.id) from users u ... | One clause per line, projection items stacked under SELECT. |
where u.active=1 and u.created_at>'2024-01-01' | AND conditions indented under WHERE. |
left join orders o on o.user_id=u.id | JOIN on its own line, ON condition indented. |
- Paste the query: Drop the minified or messy SQL into the input; a realistic sample is preloaded.
- Choose the style: Pick keyword casing and indent width to match your project.
- Format: Clauses break onto their own lines with aligned conditions.
- Copy the result: Take the formatted SQL into your migration, review or documentation.
The string '2024-01-01' passes through untouched even though formatting happened around it — the literal-protection pass guarantees that. The final query keeps its exact semantics; only layout changes.
Common errors and edge cases
- Vendor-specific syntax. Bracket identifiers (
[column]), hints and procedural blocks are not parsed; they pass through but may not be aligned perfectly. - Not a validator. The formatter beautifies invalid SQL just as happily as valid SQL. It will not catch a missing FROM or a typo in a table name.
- Keywords inside strings. Handled correctly thanks to literal protection — but escaped-quote edge cases in exotic dialects can confuse the extractor.
- Deeply nested subqueries. Parentheses trigger indentation, but complex correlated subqueries may need a manual pass for perfect readability.
- Dialect differences. Standard SQL formats cleanly; for T-SQL, PL/SQL or BigQuery specifics, run sqlfluff or your IDE's dialect-aware formatter as well.
Code equivalents
For CI pipelines and pre-commit hooks, use a real parser-backed formatter. These cover the same ground with dialect support.
| Language | Example |
|---|---|
| Python (sqlfluff) | sqlfluff fix query.sql --dialect postgres lints and reformats with full dialect awareness. |
| Python (sqlparse) | sqlparse.format(sql, reindent=True, keyword_case='upper') — the library equivalent of this tool. |
| Node.js | sqlFormatter.format(sql, { language: 'postgresql' }) with the sql-formatter package. |
Related tools
Frequently asked questions
Does the formatter change my query's meaning?
No. Only whitespace and keyword casing change; identifiers, literals and logic are preserved. String contents are protected and restored exactly.
Which SQL dialects are supported?
The formatter is dialect-agnostic and handles standard SELECT/INSERT/UPDATE/DELETE well. Vendor-specific syntax (T-SQL brackets, PL/SQL blocks, hints) is preserved but not deeply restructured.
Can it validate my SQL?
No — it is a beautifier, not a parser or linter. Invalid SQL gets formatted, not flagged. Use sqlfluff or your database's EXPLAIN for validation.
Why protect string literals first?
Because a word like where inside 'where to go' is data, not syntax. The formatter extracts quoted strings, formats around them, then restores them byte-for-byte.
Uppercase or lowercase keywords?
Pure preference — the tool supports both. Uppercase is the traditional standard and makes keywords scannable; lowercase matches modern style guides. Pick one and stay consistent.
Privacy note
All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.