Free SQL Formatter

SQL, A Brief History of the Language Being Formatted

SQL (Structured Query Language) was developed at IBM by Donald D. Chamberlin and Raymond F. Boyce in the early 1970s, originally as SEQUEL ("Structured English Query Language"), renamed to SQL after a trademark conflict. The language was first commercialised by Oracle's predecessor (Relational Software, Inc.) in 1979, Oracle V2 was the first commercial SQL database, beating IBM's own DB2 to market. The first ANSI standard, ANSI SQL-86, was published in 1986; the much more substantial SQL-92 revision (the "big" SQL standard, ISO/IEC 9075:1992) defined most of the syntax modern users recognise, JOIN syntax, set operations, subqueries, transactions. Subsequent revisions added object-relational features (SQL:1999), XML support (SQL:2003), window functions and CTEs (SQL:2003 and 2008), temporal queries (SQL:2011), JSON support (SQL:2016, expanded in SQL:2023). Each major database vendor implements its own dialect, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (PostgreSQL-compatible analytical SQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: all sharing the SQL-92 core but diverging on functions, syntax extensions, and reserved-word lists. A good formatter respects the dialect it's formatting because the same identifier might be a keyword in one dialect and a legal column name in another.

Conventions That Make SQL Readable

Several conventions have become standard in SQL style guides, Mozilla's, Simon Holywell's widely-cited SQL Style Guide, GitLab's data team conventions, dbt's recommended style. Keywords in UPPERCASE (SELECT, FROM, WHERE, JOIN) versus identifiers (table and column names) in lowercase or snake_case is the dominant convention. Some style guides advocate the opposite (lowercase keywords are easier to type and read), and the dialect documentation for PostgreSQL itself uses lowercase keywords throughout, but UPPERCASE keywords win in most professional codebases because they make the language structure visible at a glance. Each major clause on its own line: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, each starts a new line at the same indent level. JOIN conditions indented under ON: the JOIN keyword on its own line, the ON keyword on the next line indented one level. Comma-first or comma-last in column lists is a long-running stylistic argument; comma-first (each column line begins with the comma) makes adding/removing columns produce cleaner diffs and protects against the trailing-comma syntax error, but feels visually unusual to many. Comma-last is more common in production code. Subquery indentation: nested queries indented one level deeper than their parent. CTE (WITH) clauses: each named CTE on its own line, the body indented under the AS, the main query at the bottom flush-left.

When You'll Reach for a SQL Formatter

• Reading queries logged by an ORM. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, all generate SQL programmatically and emit it as a single dense line in your application logs. To debug "why is this query slow", paste the logged SQL into the formatter and read what the ORM actually produced. The result is often illuminating ("oh, that's a CROSS JOIN where I expected an INNER").
• Code review on database PRs. A SQL migration or stored procedure change is much easier to review when consistently formatted. Run the file through the formatter before committing so the diff is structural, not whitespace-noise.
• Reading EXPLAIN plans alongside the query. When tuning a slow query, you read the EXPLAIN output, then re-read the query to find the table reference at the top of the plan. A formatted query makes the cross-reference instant.
• Pasting SQL into tickets, docs, Slack. A formatted query reads cleanly; a one-line minified query is unreadable in any narrow context. Format before sharing.
• Reformatting legacy queries with mixed-case keywords. A 15-year-old codebase where SELECT was sometimes spelled Select, sometimes select, sometimes SELECT reads better after the formatter normalises everything to one convention.
• Cleaning up exported queries from BI tools. Looker, Mode, Metabase, Tableau and similar tools let you copy the underlying SQL but emit it in whatever ad-hoc format they generate. Format before reading.

The SQL Formatter Ecosystem

For command-line and editor-integrated workflows, several mature options exist. sql-formatter (npm package, originally by Andriy Isayev, now maintained by a community team) is the dominant JavaScript-ecosystem SQL formatter, supports MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB and several other dialects. pg_format (Gilles Darold) is the canonical PostgreSQL-specific formatter, written in Perl and bundled with the popular pgFormatter web service. Poor Man's T-SQL Formatter (Tao Klerks, 2011) targets Microsoft SQL Server's T-SQL dialect specifically. sqlparse (Andi Albrecht) is the standard Python library, used by Django for query analysis and by countless data-engineering scripts. SQLFluff is the modern linter-and-formatter that integrates with dbt projects and analytics workflows. JetBrains' DataGrip and the SQL plugin for IntelliJ IDEA include a sophisticated dialect-aware formatter; VS Code's SQLTools and several other extensions wrap the npm sql-formatter library. For projects with a build pipeline, the modern pattern is "format on save in the editor + a CI check that fails the build if SQL files are mis-formatted", same model as Prettier for JavaScript or Black for Python.

Dialect Differences That Matter for Formatting

Most SQL formatters work across dialects with minor adjustments, but a handful of differences require the formatter to know which dialect it's reading. Quoted identifiers: standard SQL uses double quotes ("order"); MySQL uses backticks (`order`) by default and only respects double quotes in ANSI mode; SQL Server uses square brackets ([order]). String concatenation: standard SQL uses ||; MySQL uses CONCAT() or the rarely-seen || in ANSI mode; SQL Server uses +. Pagination: MySQL/PostgreSQL/SQLite use LIMIT/OFFSET; SQL Server uses TOP or OFFSET FETCH; Oracle uses FETCH or ROWNUM. Auto-increment: AUTO_INCREMENT in MySQL, SERIAL or IDENTITY in PostgreSQL, IDENTITY in SQL Server, AUTOINCREMENT in SQLite. Reserved-word lists diverge, a column named rank needs quoting in PostgreSQL (where RANK is a window function keyword) but is fine as an identifier in MySQL. A formatter that doesn't know the dialect may break valid queries by adding inappropriate quoting. The "Format SQL" output from a generic formatter is usually correct for the standard SELECT/INSERT/UPDATE/DELETE shape; for vendor-specific syntax (window functions, hints, system functions), spot-check the output against your dialect docs.

Privacy: Why Browser-Only Matters Especially for SQL

SQL queries are some of the most sensitive text in any organisation: they expose internal table names (which reveal product taxonomy), column names (which reveal data model), filter values (which may include real user IDs, email addresses, business IDs), embedded literal credentials in older patterns, and the structure of analytics that the company may consider proprietary. Server-side SQL formatters take a copy of every query into their logs. This formatter runs entirely in your browser via JavaScript, verify in DevTools' Network tab while you click Format (no requests fire), or take the page offline (airplane mode) after it loads and the formatter still works. Safe for production queries containing real table names and PII filter values, internal analytical SQL, ETL pipelines, or any query you wouldn't want copied onto a stranger's hard drive.

Frequently Asked Questions

Can the formatter uppercase SQL keywords automatically?

Yes, the Keywords toggle controls case. UPPERCASE is the dominant professional convention because it makes the language structure visible at a glance (SELECT, FROM, WHERE stand out from identifiers); lowercase is preferred by some style guides (PostgreSQL's own documentation uses lowercase throughout) on the grounds that it's easier to read and faster to type. Either works as long as your team picks one and uses it consistently. The capitalisation has no effect on query behaviour, SQL keywords are case-insensitive at parse time.

How do I customise indentation?

The Indent dropdown supports 2 spaces (the dominant modern web convention), 4 spaces (still common in older Java and .NET shops), or tab characters. 2 spaces tends to win in newer codebases and for SQL specifically because deep subquery nesting fits more comfortably within a 100-character line limit. Match whatever convention your team already uses; consistency matters more than the specific choice.

Does this work with large queries?

Yes, because formatting runs in your browser, the practical ceiling is your device's available memory. Hundreds of lines of SQL format in well under a second; multi-thousand-line queries (typical in data-warehouse ETL) work but may briefly freeze the tab while the parser walks the structure. For batch reformatting of an entire SQL repository, command-line tools (sql-formatter via npm, pg_format for PostgreSQL, SQLFluff for dbt projects) are more appropriate.

Will the formatter recognise my specific SQL dialect?

It handles the common SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/subquery shapes correctly across MySQL, PostgreSQL, SQLite, T-SQL and standard ANSI SQL. Vendor-specific syntax (window-function clauses, MERGE statements, dialect-specific hints, system functions, PostgreSQL-style array operators, T-SQL XML methods) may format imperfectly. Spot-check the output and run the formatted query through your database to confirm it parses correctly before committing.

Is my SQL uploaded?

No. Formatting runs entirely in your browser, pasted queries never leave your device. Verify in DevTools' Network tab while you click Format (no requests fire), or take the page offline (airplane mode) after it loads. Safe for production queries containing sensitive table names, PII filter values, or any SQL covered by NDA or compliance regulation.

Related Tools