SQL Formatter & Beautifier

SQL is the format that most needs formatting and least gets it. ORM-generated queries are usually one-line affairs that wrap to ten screens in a debugger; queries copied from log files come with timestamp prefixes and trailing semicolons that need cleanup; queries pasted from documentation often arrive in a different style than the codebase uses; queries written by a teammate often follow conventions you have to mentally translate before you can read them. The formatter takes any of these inputs and produces a normalized, readable form that follows whichever style your team prefers — uppercase or lowercase keywords, trailing or leading commas, two-space or four-space indentation. The output is byte-equivalent in semantics; only the layout changes.

The implementation uses sql-formatter under the hood, which supports 17 SQL dialects and counting. The dialect picker matters because SQL is not one language — it is a family of related languages, each with its own keywords, function names, type system, and quirks. PostgreSQL has DISTINCT ON, RETURNING, and a rich set of built-in functions; T-SQL has TOP, CROSS APPLY, and a different escape convention; PL/SQL has DECLARE/BEGIN/END blocks and packaged procedures; BigQuery has UNNEST and array functions; Snowflake has its own table-function syntax. Picking the right dialect tells the formatter which keywords to recognize, how to handle the dialect-specific operators, and what conventions to follow for the output. If you pick the wrong dialect, the formatter will do its best — usually treating the unknown keywords as identifiers — but the output will be slightly off.

Keyword case is the configuration knob most teams care about most. The three options — UPPERCASE, lowercase, Capitalize — cover the conventions you will see in the wild. UPPERCASE is the long-standing default in many shops because it makes keywords visually distinct from identifiers in tools that do not syntax-highlight; it is also the official style in many vendor documentation sets. lowercase is the modern alternative, championed by newer style guides on the grounds that mixed-case looks calmer and is faster to type without a finger reach. Capitalize (initial-cap on each keyword) is rare but lives on in some legacy codebases; the option is here for completeness. Pick one and stick with it across files; the formatter normalizes regardless of how the input was authored.

Comma position is the second knob worth considering. The two conventions are trailing commas (the SELECT clause ends each line with a comma except the last) and leading commas (each line after the first begins with a comma). Trailing is what most people learned first and what most ORM-generated SQL produces. Leading commas have a strong following among DBAs and SQL-heavy codebases because they make it easy to comment out individual columns (the comma is at the start of the next line, so commenting out a line does not leave a dangling comma) and they align the column names visually. The formatter supports both; pick what your team uses.

Indentation choices are the third knob. Two-space is the most common modern preference; four-space is the long-standing convention in many enterprise SQL codebases; tab indentation appears in some legacy systems. The formatter handles all three. The structural shape of the output (where SELECT, FROM, WHERE, GROUP BY, ORDER BY land relative to each other) follows the standard SQL formatting style, which most readers will recognize regardless of indent size: SELECT on its own line, columns one per line indented one level, FROM on its own line, joins indented and aligned, WHERE clause conditions one per line indented, etc. Subqueries and CTEs (Common Table Expressions) are indented under their parent.

Where the formatter helps real work. Reviewing a query plan: an EXPLAIN ANALYZE of an unformatted query is impossible to map back to the SQL because the plan refers to operators and join orders that are easier to recognize when the source is formatted; format the query first, then read the plan against it. Debugging a failing query: the line numbers in the error message line up only with formatted source; an unformatted single-line query gives you a useless 'error at line 1, column 8137' message. Code review: a SQL change in a pull request is easier to review when the diff lines up with logical clauses, which only happens when the formatter is applied consistently. Documentation: SQL examples in technical docs read better when formatted to your audience's expected style.

Where the formatter helps tooling. Database migration scripts that need to live in version control benefit from formatting because git diffs become meaningful — you can see which clauses changed across two versions of a migration. ORM-generated queries that you paste into a SQL client for direct execution become editable when formatted; the one-line ORM output is hard to modify precisely because line-based editing relies on logical line breaks. Saved queries in a query workbook benefit from consistent formatting so they read as a single body of work rather than a Frankenstein assembly of styles.

Edge cases worth knowing. CTEs (WITH clauses) format with each CTE on its own line, indented under the WITH keyword. Recursive CTEs (WITH RECURSIVE) are handled the same way. Window functions (OVER (PARTITION BY ... ORDER BY ...)) format with the OVER clause on the same line as the function call when short, or wrapped onto its own line when long. Joins format with each ON clause indented under its JOIN. UNION / INTERSECT / EXCEPT format with each branch as its own SELECT, with the set operator on its own line. Stored procedures and triggers (the syntax-heavy parts of T-SQL and PL/SQL) format with reasonable indentation but have so many dialect-specific constructs that the output occasionally needs hand-tuning.

Multi-statement scripts (a single input with multiple semicolon-separated statements) are handled — the formatter formats each statement independently and concatenates them with blank lines between. The statement count tile in the UI tells you how many statements were detected. If your input is a long migration script with hundreds of statements, the formatter will handle it; the output will be long but readable. For genuinely massive scripts (thousands of statements) the browser tab will struggle, and you should use a command-line formatter instead.

Privacy is the same model as the rest of our tools: nothing is uploaded, nothing is logged, the formatter runs entirely in your browser. The SQL you paste — including any literal values, internal table names, or patterns that reveal something about your database structure — never leaves your device. This matters because production SQL often contains hints about your data model, your business logic, or the specific patterns your application uses, and corporate security policies typically forbid pasting that into third-party services. Verify by opening the network tab during formatting; no outbound requests are made.

Workflow tip: format the SQL, then run it. A query that you intend to execute against a production database is safer to read after formatting because the structure is visible at a glance — you can spot a missing WHERE clause, a swapped join condition, or a typo in an aggregate function before you hit Run. A formatter is not a linter (it will not catch logic errors), but the visual normalization makes manual inspection easier. For genuine linting (catching ambiguous joins, missing indexes, deprecated syntax), use a dedicated SQL linter as part of your CI pipeline.

The tool pairs with the rest of the developer suite. The JSON Viewer is useful when SQL queries return JSON columns (PostgreSQL, MySQL, BigQuery all support JSON now). The JSON to TypeScript generator turns query result samples into types you can import. The Regex Tester is the right place to debug LIKE patterns or CHECK constraint regex before pasting them into your DDL. The Hash Generator is helpful when generating fixed-length keys for partition columns or stable hash-based shard keys. Together with the formatter, these cover most of the SQL author's daily formatting and inspection needs.