SQL Formatter
Format and beautify SQL queries. Uppercase keywords and proper indentation.
Format messy SQL queries into clean, readable code. Automatically uppercases keywords, adds proper indentation, and supports SELECT, INSERT, UPDATE, and more.
Raw SQL from logs, ORMs, or a colleague's chat message is usually a single line with lowercase keywords and no indentation. Reading it is slow, reviewing it for bugs is slower. A formatter rewrites the query with each clause on its own line, keywords uppercased, and joins and subqueries indented so the structure becomes obvious. You can see at a glance whether the WHERE clause is attached to the right SELECT, whether a JOIN is missing an ON, or whether a subquery is returning what you expect.
The formatter understands the major dialects — PostgreSQL, MySQL, SQL Server T-SQL, Oracle PL/SQL, BigQuery, Snowflake, and SQLite — so dialect-specific keywords like RETURNING, LIMIT OFFSET, TOP, or QUALIFY are handled correctly instead of being split onto awkward lines. Window functions, CTEs, CASE expressions, and nested subqueries each get their own indentation rules, which matters because a real analytical query can easily hit five levels of nesting.
Formatting runs locally. Paste a production query you'd rather not send to a third-party service, get clean output, and paste it straight into a pull request, a migration file, or a Slack thread.
- 1
Paste the query
Drop any SQL — a one-liner from a log, an ORM-generated monster, or a draft you're writing. Any dialect works.
- 2
Choose dialect and style
Pick PostgreSQL, MySQL, T-SQL, Oracle, BigQuery, Snowflake, or SQLite. Set indent size, keyword case (upper, lower, capitalize), and whether commas lead or trail.
- 3
Copy the formatted result
The output is ready for a migration file, a PR comment, or a docs page. Keyword case is normalized and clauses aligned so the query structure is readable at a glance.
Reviewing ORM-generated SQL
Prisma, Sequelize, and SQLAlchemy often emit dense single-line queries. Format them to review N+1 problems or missing indexes.
Documenting complex reports
Format a 200-line analytical query with CTEs and window functions before embedding it in runbook documentation.
Pull request hygiene
Paste a new migration's SQL through the formatter so every PR uses the same style regardless of who wrote the query.
Debugging slow queries
Pretty-print a query from pg_stat_statements or the slow-query log so you can reason about join order and filter placement.
Which SQL dialects are supported?
PostgreSQL, MySQL, SQL Server (T-SQL), Oracle, BigQuery, Snowflake, Redshift, SQLite, and a generic ANSI fallback. Dialect-specific keywords like QUALIFY, RETURNING, and TOP format correctly in their native dialects.
Does the formatter change my query's behavior?
No. It only reshapes whitespace and keyword case. The token stream is identical, so the query planner sees the exact same SQL.
Can it handle multiple statements?
Yes. Paste a full migration file with multiple semicolon-separated statements and each one gets formatted independently.
How does it handle CTEs and window functions?
WITH clauses get their own indentation block, and each window function's OVER() clause is broken onto its own line when it's long enough that leaving it inline would cause horizontal scroll.
Can I configure the style?
Indent size (2 or 4 spaces or tabs), keyword case (upper/lower/capitalize), and comma position (leading or trailing) are configurable. Defaults follow the common convention for each dialect.