SQL Formatter

SQL That a Human Can Review

ORM debug output. A copied query from a monitoring dashboard. Legacy stored procedures. All of them arrive looking like this:

SELECT u.id,u.name,u.email,o.total,o.created_at FROM users u INNER JOIN orders o ON u.id=o.user_id WHERE o.total>100 AND u.status='active' AND u.created_at>'2024-01-01' ORDER BY o.total DESC LIMIT 20 OFFSET 0

And after formatting:

SELECT
    u.id,
    u.name,
    u.email,
    o.total,
    o.created_at
FROM users u
INNER JOIN orders o
    ON u.id = o.user_id
WHERE o.total > 100
    AND u.status = 'active'
    AND u.created_at > '2024-01-01'
ORDER BY o.total DESC
LIMIT 20
OFFSET 0

Same query. The formatted version shows you the JOIN condition, the three WHERE clauses, and the sort order at a glance. The minified version requires counting commas to know there are five selected columns.

What the Formatter Does

Keyword uppercasing: SQL conventions (and many style guides) require keywords in uppercase. select, from, where become SELECT, FROM, WHERE — clearly distinguishing keywords from table and column names.

Clause-level line breaks: Each major clause (SELECT, FROM, JOIN, WHERE, AND/OR, ORDER BY, GROUP BY, HAVING, LIMIT) moves to its own line, creating a top-to-bottom readable structure.

SELECT-list indentation: When multiple columns are selected, each column appears on its own indented line — making it easy to see exactly what the query returns.

Subquery indentation: Inline subqueries inside parentheses are indented an extra level, visually separating them from the outer query.

Minify mode: Strips all indentation and line breaks to produce a single-line query — useful for embedding SQL in logs, string constants, or API payloads.

Supported SQL Dialects

The formatter applies standard ANSI SQL formatting rules, which work well across:

Dialect-specific procedural extensions (PL/pgSQL BEGIN...END blocks, T-SQL DECLARE, stored procedure syntax) may format imperfectly — the formatter handles standard SQL queries, not full procedural code.

When Developers and DBAs Use This

Debugging ORM queries: ActiveRecord, Hibernate, Eloquent, and SQLAlchemy all log their generated SQL in compact form. Paste the logged query here to see what the ORM actually sent to the database.

Code reviews of migrations: When reviewing pull requests containing schema migrations or stored procedures, formatted SQL is dramatically easier to audit for correctness, injection risks, and performance issues.

Git diffs on SQL files: Consistently formatted SQL in migration files makes git diff output useful — you can see which specific column was added or which condition changed rather than parsing a character-by-character single-line diff.

Documentation: Technical documentation, SQL playbooks, runbooks, and wikis need well-formatted queries. Readers shouldn't need to mentally parse minified SQL to understand the query's logic.

Query analysis: Before explaining a query to a colleague or documenting its logic, format it first so the structure is visible at a glance.

Best Practices

Format during development, minify only for production logs. Keep formatted SQL in your codebase and migration files. Minified versions are for production query logging systems that store SQL in single-line format.

Commit formatted SQL. Consistent SQL formatting in version control makes future maintenance easier. When a query needs to change, formatted SQL shows precisely which part changes.

Format before optimizing. Before running EXPLAIN ANALYZE, format the query so the join structure and filter conditions are readable. You'll spot potential performance issues (missing WHERE clause filters, unnecessary columns in SELECT, implicit cross-joins) much faster.

Limitations

Regex-based, not AST-based. This formatter uses pattern matching on SQL keywords rather than a full syntax tree parser. It handles standard SQL queries well, but deeply nested subqueries or unusual syntax may have minor formatting quirks.

Doesn't validate SQL. A query with a syntax error (mismatched parentheses, missing FROM) will format the text as-is. The formatter doesn't execute or parse the SQL — test your query in your database after formatting.

Procedural SQL is not fully supported. PL/pgSQL, T-SQL stored procedures, and other procedural extensions may not format correctly beyond their core SQL statements.

Formatting ≠ optimization. A beautifully formatted query is still slow if it has a missing index or an N+1 problem. Use your database's EXPLAIN plan for performance analysis.

Related Developer Tools

• JSON Formatter — Format API responses alongside SQL results
• XML ↔ JSON Converter — Convert data formats for SQL import/export
• Regex Tester — Build and test patterns for SQL string parsing
• UUID Generator — Generate IDs for database records and test data

Recommended schema: SoftwareApplication + FAQPage