SQL Formatter
Format SQL queries with proper indentation and uppercase keywords.
How to Use
- Paste your SQL query (or a multi-statement script) into the input area.
- Pick keyword case: UPPERCASE (traditional), lowercase (modern), or Preserve.
- Pick indent width (2, 4, or 8 spaces).
- Click Format — output appears in the right panel with line breaks at major clauses (SELECT, FROM, WHERE, JOIN, GROUP BY, etc.).
- Click Copy to put the formatted query on your clipboard.
- Works for any major dialect — MySQL, PostgreSQL, SQLite, SQL Server, Oracle.
Formatting Rules
A Brief History of SQL
SQL was developed at IBM in the early 1970s by Donald Chamberlin and Raymond Boyce, originally as "SEQUEL" — Structured English Query Language. The name was shortened for trademark reasons. Edgar F. Codd's 1970 paper proposing the relational model created the theoretical foundation; SQL became the language IBM (and later many others) used to query relational databases. Oracle Corporation released the first commercial SQL database in 1979.
SQL was standardized by ANSI in 1986 and ISO in 1987, with periodic revisions adding new features: window functions and CTEs (SQL:1999), XML and Boolean types (SQL:2003), JSON support (SQL:2016), and most recently the SQL/PGQ graph extension (SQL:2023). Despite the standard, every major database has its own dialect with proprietary extensions — which is why "generic" SQL formatters like this one focus on standard clauses and rely on the user to verify dialect-specific output.
SQL is one of only a handful of programming languages from the 1970s still in mainstream use unchanged in basic form. The reason is simple: relational databases are still the right answer for most data persistence problems, and SQL is still the right interface to relational data. Modern developments (column stores, distributed SQL, NewSQL, lakehouses) all use SQL as the surface language because of its 50-year track record and universal familiarity.
About This Formatter
This formatter uses pattern-matching to identify SQL clauses, keywords, and structural elements, then re-emits the query with consistent indentation and line breaks. It targets the broad standard SQL grammar with concessions for the most common dialect-specific features (backticks, brackets, double-quoted identifiers).
Everything runs entirely in your browser. SQL is never transmitted, logged, or stored — you can paste production queries with sensitive table or column names without exposure. For maximally precise formatting that respects every dialect feature, dbt's {% raw %}{{ format_sql() }}{% endraw %} macro or sqlfluff (Python) handle edge cases this regex-based approach can miss.
Frequently Asked Questions
Why bother formatting SQL?
Readability. A 200-line query on one line is impossible to scan or debug; the same query with one clause per line, indented joins, and aligned columns becomes parseable at a glance. Code review, version control diffs, and SQL refactoring all benefit hugely from consistent formatting. Most professional teams adopt a style guide and enforce it via formatters or linters.
Should keywords be UPPERCASE or lowercase?
Pure style choice. Traditional convention (going back to early SQL standards) puts keywords in UPPER and identifiers in lower so they visually stand out. Modern teams (especially in tools like dbt) increasingly prefer all-lowercase for less visual noise. Pick one, document it, and stick with it across your codebase.
Does this validate the SQL?
No — it formats whatever you paste in, even if it has syntax errors. Use a real SQL parser or your database's EXPLAIN command for validation. The formatter handles malformed queries gracefully (it won't crash) but the output won't tell you why the query is broken.
Will it understand my dialect-specific features?
It handles standard SQL clauses (SELECT/FROM/WHERE/JOIN/GROUP BY/ORDER BY/LIMIT, common aggregates, subqueries) and most common dialect features (PostgreSQL window functions, MySQL backticked identifiers, SQL Server bracketed identifiers). Highly dialect-specific syntax (T-SQL stored procedures, PL/SQL blocks, PostgreSQL DO blocks) may not format optimally.
What about CTEs and window functions?
Common Table Expressions (WITH clauses) format as multi-line blocks. Window functions (OVER ... PARTITION BY ... ORDER BY) format with their own indentation. Modern SQL constructs are handled, though deeply nested queries may need manual cleanup after formatting.
Is my query stored anywhere?
No. Everything runs entirely in your browser using regex-based formatting; the SQL is never transmitted to a server. You can safely paste production queries containing column names, table names, or even sample values from sensitive databases without exposure.
Common Use Cases
Code review preparation
Format a query before submitting a pull request so reviewers can read it without squinting.
Cleaning up auto-generated SQL
ORM-generated queries (Hibernate, ActiveRecord, SQLAlchemy) are often single-line. Format them to inspect what's actually being executed.
Documentation and Stack Overflow
Format complex examples for blog posts, internal documentation, or troubleshooting tickets.
Migration scripts
Make multi-statement migrations readable so your team can review them line-by-line.
Performance debugging
Format a slow query before pasting into EXPLAIN ANALYZE — easier to map plan output to clauses.
Teaching and training
Show students the structure of joins, subqueries, and window functions through visual indentation.
Last updated: