SQL Formatter & Beautifier

About This SQL Formatter

I built this SQL formatter after years of working with database queries across production systems. Whether you are debugging a slow query pulled from a log file, reviewing SQL in a code review, or preparing a query for documentation, having consistently formatted SQL makes everything easier to read and reason about. This tool runs entirely in your browser, which means your queries never leave your machine. There is no server, no logging, and no analytics on the content you paste here.

The formatter supports five dialect modes. Standard SQL covers the ANSI SQL specification that works across most database engines. MySQL mode adds keywords like ENGINE, CHARSET, GROUP_CONCAT, and REGEXP. PostgreSQL mode includes SERIAL, BIGSERIAL, ILIKE, LATERAL, and JSONB. SQLite mode recognizes AUTOINCREMENT, GLOB, and PRAGMA. SQL Server mode handles IDENTITY, NVARCHAR, MERGE, PIVOT, TRY/CATCH, and GO batch separators.

How SQL Formatting Works

SQL formatting follows a set of conventions that make queries easier to read. The basic principle is that each major clause starts on its own line, and nested elements are indented to show their relationship to the parent clause. Here is how the formatter handles different parts of a query.

Major Clause Separation

Each top-level clause in a SELECT statement gets its own line. This includes SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, and OFFSET. When you look at a formatted query, you can immediately see the overall structure without parsing through a wall of text.

JOIN Formatting

Each JOIN clause starts on its own line at the same indentation level as FROM. The ON condition is indented one level deeper. This makes it clear which tables are being joined and on what conditions. For complex queries with many joins, this visual separation is important for understanding the data flow.

Subquery Handling

Subqueries are indented inside their enclosing parentheses. Each level of nesting adds another level of indentation, making it possible to trace the execution order. Correlated subqueries, scalar subqueries in the SELECT list, and subqueries in WHERE conditions all follow the same indentation pattern.

CASE Expression Formatting

CASE expressions are formatted with WHEN and THEN on separate lines, each indented one level from CASE. The ELSE clause aligns with WHEN, and END aligns with CASE. This formatting is particularly useful when CASE expressions contain multiple conditions or are used within aggregate functions.

Common Table Expressions

WITH clauses (CTEs) are formatted with the CTE name and AS keyword on one line, followed by the CTE body indented inside parentheses. Multiple CTEs are separated by commas, with each one starting on a new line. Recursive CTEs follow the same pattern with the RECURSIVE keyword appearing after WITH.

SQL Formatting Conventions by Dialect

MySQL Formatting

MySQL has several dialect-specific features that affect formatting. The backtick character is used for identifier quoting instead of double quotes. AUTO_INCREMENT appears in CREATE TABLE statements. MySQL-specific functions like GROUP_CONCAT with SEPARATOR, IFNULL, and the REGEXP operator are recognized and highlighted. The ENGINE and CHARSET clauses in CREATE TABLE statements are formatted on separate lines after the closing parenthesis.

MySQL also supports the DELIMITER statement for stored procedures, which changes the statement terminator. This formatter recognizes DELIMITER and keeps it on its own line. The SHOW, DESCRIBE, USE, LOCK, and Access statements are also recognized as MySQL-specific keywords.

PostgreSQL Formatting

PostgreSQL extends standard SQL with several effective features. The SERIAL and BIGSERIAL types for auto-incrementing columns are recognized. The ILIKE operator for case-insensitive pattern matching is highlighted as a keyword. LATERAL joins, which allow subqueries to reference columns from preceding items in the FROM clause, are properly formatted.

PostgreSQL's JSONB operators and functions are commonly used in modern applications. The formatter recognizes JSON path expressions and jsonb functions. ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE (upsert syntax) are formatted with proper indentation. MATERIALIZED views and CONCURRENTLY operations for index creation are also supported.

SQLite Formatting

SQLite uses a simplified SQL dialect with some unique features. AUTOINCREMENT (one word, unlike MySQL's AUTO_INCREMENT) is recognized. The GLOB function, which is similar to LIKE but case-sensitive and uses Unix glob syntax, is highlighted. PRAGMA statements for database configuration are formatted on their own lines. ATTACH and DETACH for multi-database operations are also supported.

SQL Server Formatting

SQL Server (T-SQL) has the most extensive dialect-specific features. IDENTITY columns, NVARCHAR types, and GETDATE() are recognized. The NOLOCK hint is highlighted as a keyword. MERGE statements with MATCHED and NOT MATCHED clauses are formatted with proper indentation for each action.

The GO batch separator is treated as a statement terminator and always appears on its own line. TRY/CATCH blocks for error handling are formatted with BEGIN and END aligned. EXEC and EXECUTE are recognized for stored procedure calls. PIVOT and UNPIVOT operations are indented to show their relationship to the source data.

Why SQL Formatting Matters

Consistent SQL formatting is not just about aesthetics. It directly impacts code quality, debugging speed, and team collaboration. In my experience working with database-heavy applications, well-formatted SQL reduces the time spent understanding and modifying queries by at least half.

Readability in Code Reviews

When SQL queries are embedded in application code, they are often written as single-line strings or minimally formatted. During code reviews, reviewers need to understand the query logic to verify correctness. A compact query like "SELECT u.id, u.name FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.total > 100 AND u.active = 1 GROUP BY u.id, u.name HAVING COUNT(*) > 5 ORDER BY u.name" is much harder to review than the same query spread across multiple properly indented lines.

Debugging Performance Issues

When a query appears in a slow query log or an EXPLAIN output, it is typically in a compact format. Formatting the query before analyzing it makes it possible to see which tables are involved, what join conditions exist, and where filter conditions are applied. This is especially important for queries with subqueries, where the execution order depends on whether the subquery is correlated or not.

Documentation and Knowledge Sharing

SQL queries in documentation, runbooks, and migration scripts should be formatted for readability. A new team member reading a schema migration should be able to understand the changes at a glance. Formatted SQL with comments makes database changes self-documenting.

Version Control Diffs

When SQL files are tracked in version control, consistent formatting produces clean diffs. If one developer formats a query one way and another reformats it differently, the diff shows the entire query as changed even if only one condition was modified. A shared formatting standard eliminates this noise and makes code history meaningful.

SQL Formatting Compared to Other Approaches

IDE Built-in Formatters

Most database IDEs like DataGrip, DBeaver, and SQL Server Management Studio include built-in SQL formatters. These work well for their specific database dialect but often lack support for other dialects. A web-based formatter like this one is useful when you need to quickly format a query without opening an IDE, or when you are working with a dialect your IDE does not support.

Command-Line Tools

Tools like sqlfluff, pg_format, and sql-formatter-cli provide command-line formatting that can be integrated into CI/CD pipelines and pre-commit hooks. These are excellent for enforcing formatting standards in a project, but they require installation and configuration. This web tool fills the gap for quick, one-off formatting tasks.

Editor Extensions

VS Code, Sublime Text, and other editors have SQL formatting extensions. These are convenient for formatting SQL within your editor workflow. However, they may not highlight the output or provide query statistics. This tool combines formatting, highlighting, and analysis in a single interface.

Tips for Writing Maintainable SQL

Use Explicit JOIN Syntax

Always use INNER JOIN, LEFT JOIN, and other explicit join keywords instead of comma-separated tables with WHERE conditions. Explicit joins make the query structure clear and separate join conditions from filter conditions. The implicit join syntax (FROM a, b WHERE a.id = b.a_id) is harder to read, easier to get wrong with missing conditions, and deprecated in some contexts.

Qualify Column Names

When a query involves more than one table, always prefix column names with the table alias. Instead of "SELECT id, name" write "SELECT u.id, u.name". This eliminates ambiguity, prevents errors when tables have columns with the same name, and makes it immediately clear where each column comes from.

Use CTEs for Complex Queries

Common Table Expressions (WITH clauses) let you name intermediate result sets and reference them in the main query. Instead of nesting subqueries three levels deep, you can define each step as a CTE with a meaningful name. This makes complex analytical queries read almost like a series of simple statements.

Comment Complex Logic

SQL comments (-- for single line, /* */ for multi-line) should explain why a condition exists, not what it does. "-- Exclude test accounts created by QA team" is much more useful than "-- filter where active = 1". The formatter preserves all comments and highlights them in a distinct color so they remain visible in the formatted output.

Keep Queries Under 50 Lines

If a formatted query exceeds about 50 lines, consider breaking it into CTEs or temporary tables. Very long queries are difficult to understand, test, and improve. Each CTE or temporary table can be tested independently, and the database optimizer may handle them differently from deeply nested subqueries.

Understanding Query Statistics

This formatter provides six statistics about your query that can help you understand its complexity and potential performance characteristics.

The line count tells you how many lines the formatted query spans. Queries over 50 lines should be reviewed for opportunities to simplify. The character count is useful for checking against database client limits or query size restrictions in some ORMs. The keyword count gives a rough measure of query complexity. The table reference count shows how many tables are accessed, which correlates with the number of potential join operations the database engine needs to perform.

The join count specifically identifies how many JOIN operations appear in the query. Each join adds a potential performance cost, especially on large tables without proper indexes. The subquery count identifies nested SELECT statements, which may be executed once per row of the outer query if they are correlated subqueries.

Security Considerations

This tool processes SQL queries entirely in your browser. No data is transmitted to any server. The page does not use cookies for query data, does not store queries in local storage, and does not include any third-party analytics that could capture input content. This makes it safe to use with production SQL that references real table names, column names, or contains literal values.

However, I recommend being cautious about pasting SQL that contains sensitive literal values such as passwords, API keys, or personally identifiable information. Even though this tool does not transmit data, your browser's autocomplete or clipboard history might retain the values. Consider replacing sensitive literals with placeholder values before formatting.

Common SQL Formatting Mistakes

Inconsistent Indentation

Mixing tabs and spaces, or using different indent levels for the same type of clause, makes queries harder to read. Pick one indentation style (2 spaces, 4 spaces, or tabs) and apply it consistently. This formatter enforces your chosen style across the entire query.

Comma Placement

There is an ongoing debate about whether commas should trail (column1, column2,) or lead (, column1, column2) in SQL column lists. Trailing commas are more common in general programming, while leading commas make it easier to comment out individual columns and produce cleaner diffs. This formatter uses trailing commas, which is the more widely adopted convention.

Missing Aliases

Skipping table aliases in multi-table queries leads to ambiguous column references. Even if no column names currently conflict, adding a table later could break the query. Using short, meaningful aliases (u for users, o for orders) keeps queries compact while remaining clear.

Overly Long Lines

Some developers put all columns in a SELECT list on one line, leading to horizontal scrolling. The formatter places each major clause on its own line, but does not split column lists automatically. For SELECT statements with many columns, consider manually placing each column on its own line.

SQL Query Optimization and Formatting

Formatting a query is often the first step in optimizing it. When you can clearly see the structure of a query, performance bottlenecks become more visible. Here are some optimization patterns that become apparent once a query is properly formatted.

Identifying Unnecessary Joins

When a query is compressed onto a single line, it is easy to miss unnecessary joins. A formatted query shows each join on its own line, making it straightforward to check whether every joined table actually contributes columns to the SELECT list or conditions to the WHERE clause. If a table is joined but none of its columns are used, removing that join can significantly improve performance.

This is particularly common in queries that were originally written for a broader purpose and later modified. The original query might have selected columns from five tables, but a modification reduced it to three. The remaining two joins are dead code that the database still executes. On a table with millions of rows, an unnecessary join can add seconds to query execution time.

Spotting Missing WHERE Conditions

A formatted query with the WHERE clause clearly separated makes it easy to verify that all necessary filter conditions are present. Cross joins (cartesian products) are one of the most common SQL mistakes, and they typically occur when a WHERE condition that connects two tables is accidentally omitted. In a formatted query, you can visually trace each table in the FROM clause and verify that it has a corresponding join or filter condition.

Recognizing Subquery Optimization Opportunities

When subqueries are properly indented, you can see whether a subquery is correlated (references the outer query) or uncorrelated. Uncorrelated subqueries execute once and return a fixed result. Correlated subqueries execute once per row of the outer query, which can be extremely slow on large datasets. Formatted SQL makes this distinction visible by showing the relationship between inner and outer query references.

Many correlated subqueries can be rewritten as joins or window functions. For example, a subquery that finds the maximum order total for each customer can be replaced with a window function like MAX(total) OVER (PARTITION BY customer_id). The formatted version of both approaches makes it clear which one is more fast for your specific use case.

Evaluating Index Usage

A formatted WHERE clause shows the exact conditions being filtered. You can check whether each condition column is indexed. In a multi-column index, the order of columns matters. If your WHERE clause filters on columns A, B, and C, but your composite index is on (A, C, B), the index may not be fully used. Formatting the query and comparing it against your index definitions helps identify these mismatches.

SQL Style Guides and Standards

Several organizations and open-source projects have published SQL style guides. While no single standard is universally adopted, most guides agree on the basic principles that this formatter implements.

The SQL Style Guide by Simon Holywell

This widely-referenced guide recommends uppercase keywords, right-aligned keywords (so that the data references all start at the same column), and river formatting where possible. The guide emphasizes that SQL is a declarative language and should be formatted to read like a specification rather than imperative code. While this formatter uses left-aligned keywords (which is more common in practice), the uppercase keyword convention aligns with this guide's recommendation.

GitLab SQL Style Guide

GitLab's internal SQL guide requires lowercase keywords, 4-space indentation, and trailing commas. They recommend CTEs over subqueries and explicit column naming in GROUP BY (rather than positional references like GROUP BY 1, 2, 3). This formatter supports their lowercase keyword preference through the keyword case dropdown.

Mozilla SQL Style Guide

Mozilla's guide uses uppercase keywords, 2-space indentation, and leading commas. They require explicit table aliases, meaningful CTE names, and comments explaining business logic. The guide also addresses specific BigQuery and Spark SQL conventions for data engineering workflows.

Corporate Database Teams

In my experience consulting with enterprise database teams, the most common corporate SQL standard uses uppercase keywords, 4-space indentation, and each column on its own line in SELECT lists. Companies with large data warehouses tend to be the most strict about formatting standards because their queries are frequently reviewed, modified, and shared across multiple teams.

Working with Large SQL Files

This formatter handles individual queries, but many real-world SQL files contain hundreds or thousands of lines with multiple statements. Here are some approaches for managing large SQL files.

Migration Files

Database migration files (used by tools like Flyway, Liquibase, Rails migrations, and Django migrations) often contain multiple DDL statements. Each CREATE TABLE, ALTER TABLE, and CREATE INDEX statement should be separated by a blank line and formatted independently. Comments at the top of the file should explain the purpose of the migration and any dependencies.

Stored Procedures

Stored procedures combine SQL with procedural logic (variables, loops, conditionals). The formatting rules for the SQL portions follow the same principles as standalone queries, but the procedural wrapper code (DECLARE, IF/ELSE, WHILE, BEGIN/END) follows language-specific conventions. MySQL uses DELIMITER to change the statement terminator. PostgreSQL uses $$ dollar-quoting. SQL Server uses BEGIN/END blocks without a delimiter change.

Seed and Test Data Scripts

INSERT statements for test data should be formatted with each VALUES set on its own line. For bulk inserts with many columns, aligning the values with the column names makes it easier to verify correctness. This is especially important when creating test data for complex schemas where foreign key relationships must be maintained.

SQL Formatting in Different Environments

Application Code

SQL queries embedded in application code (Python, JavaScript, Java, Go, Ruby) are often written as string literals. Formatting these queries for readability while keeping the application code clean is a challenge. Multi-line strings (template literals in JavaScript, triple-quoted strings in Python, raw strings in Go) allow formatted SQL within application code. This formatter can help you format the SQL before pasting it into your application code.

ORMs and Query Builders

Object-Relational Mappers like SQLAlchemy, ActiveRecord, Django ORM, and Prisma generate SQL from application-level abstractions. When debugging ORM-generated queries, you often need to examine the raw SQL output. This SQL is typically compact and unformatted. Pasting it into this formatter makes it readable, which helps you understand what the ORM is doing and whether it is generating fast queries.

Database Administration

Database administrators frequently work with system queries that inspect database metadata. These queries against information_schema, pg_catalog, sys.tables, and similar system views can be complex. Formatting them reveals the structure and makes it easier to modify them for specific diagnostic tasks. DBA playbooks and runbooks benefit enormously from consistently formatted SQL.

Data Analysis and Reporting

Analysts writing SQL for business intelligence tools like Looker, Mode, Metabase, and Superset need their queries to be readable by both technical and non-technical stakeholders. Formatted SQL with clear column aliases and comments makes it possible for business users to understand what metrics a query calculates and how they are filtered.

modern SQL Constructs and Formatting

Window Functions

Window functions (OVER, PARTITION BY, ORDER BY within OVER) are among the most effective SQL features. Formatting window functions on separate lines makes the partitioning and ordering logic clear. A window function like ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) should be broken across lines to show the partition key and sort order separately.

Recursive CTEs

Recursive Common Table Expressions are used for hierarchical data like organizational charts, file system trees, and bill of materials. A recursive CTE has two parts separated by UNION ALL: the anchor member (base case) and the recursive member (which references the CTE itself). Formatting these on separate lines with the anchor member clearly distinguished from the recursive member makes the logic understandable.

MERGE Statements

The MERGE statement (also called UPSERT) combines INSERT, UPDATE, and DELETE operations into a single statement. It is most commonly used in SQL Server and Oracle, and PostgreSQL has its own syntax with ON CONFLICT. Formatting a MERGE statement requires clear separation of the MATCHED and NOT MATCHED clauses, with the actions (UPDATE SET, INSERT VALUES, DELETE) indented under each condition.

PIVOT and UNPIVOT

SQL Server's PIVOT and UNPIVOT operators change row-based data into columns and vice versa. These operations have a complex syntax that benefits greatly from formatting. The aggregation function, the column being pivoted, and the IN list of values should each appear on separate lines. Without formatting, PIVOT queries are nearly impossible to read.

Keyboard Shortcuts and Workflow Tips

To format SQL quickly, paste your query into the input area and press the Format button. The output appears instantly with syntax highlighting. Here are some workflow tips for common scenarios.

When working with a slow query log, copy the query from the log, paste it into the input area, select the appropriate dialect, and click Format. The formatted output will make it immediately clear which tables and conditions are involved. Copy the formatted version back for use in your analysis.

For code reviews, paste the SQL from the pull request into the formatter. The formatted version with syntax highlighting is easier to review than a compact string literal in application code. You can then compare the formatted query against the database schema to verify join conditions and column references.

When documenting queries for runbooks or playbooks, format the query here first, then copy the formatted output. Add comments explaining the business logic and any parameters that need to be adjusted. Consistently formatted documentation queries make it possible for on-call engineers to understand and modify queries under pressure.

Comparing SQL Formatting Tools

There are many SQL formatting tools available, each with different strengths. Here is how this formatter compares to common alternatives.

Online formatters like SQLFormat.org, EverSQL, and Instant SQL Formatter are popular choices. Some of these send your SQL to a server for processing, which may not be acceptable for production queries containing sensitive data. This formatter processes everything client-side, making it safe for any query regardless of content.

IDE-based formatters in DataGrip, DBeaver, and Azure Data Studio offer tight integration with database connections and schema awareness. They can auto-complete table and column names and validate queries against the actual schema. However, they require installation and setup. This web-based tool requires no installation and works from any browser.

CLI tools like sqlfluff and pgFormatter can be integrated into git pre-commit hooks to enforce formatting standards automatically. This is ideal for teams that want to ensure all committed SQL follows a consistent style. However, these tools require configuration and may have different formatting rules than what you expect. This web formatter gives you immediate visual feedback on the formatting result.

SQL Formatting for Specific Use Cases

Data Warehouse Queries

Data warehouse environments like Snowflake, BigQuery, Redshift, and Databricks use SQL with platform-specific extensions. Snowflake adds QUALIFY for filtering window function results. BigQuery uses STRUCT and ARRAY types extensively. Redshift extends PostgreSQL syntax with distribution keys and sort keys. While this formatter does not include these platform-specific keywords in its highlighting, the core formatting logic works correctly for all of these platforms because they are built on standard SQL foundations.

Data warehouse queries tend to be longer and more complex than transactional queries. They often involve multiple CTEs, window functions, and aggregate calculations across large fact tables. Formatting these queries is not optional; it is a prerequisite for understanding and maintaining them. A 200-line analytical query without formatting is effectively unreadable.

ETL Pipeline Queries

Extract-change-Load pipelines use SQL for data transformation steps. These queries often include CASE expressions for data mapping, COALESCE for null handling, string functions for data cleaning, and date functions for time-based partitioning. Formatting ETL queries clearly shows the transformation logic, making it easier to debug data quality issues and modify transformation rules.

A common pattern in ETL pipelines is a staging query that cleans raw data, followed by a merge query that upserts the cleaned data into a target table. Formatting both queries consistently and adding comments that explain the business rules behind each transformation makes the pipeline maintainable by team members who did not write the original code.

Database Schema Definition

CREATE TABLE statements benefit from formatting that aligns column definitions, constraints, and data types. Each column should appear on its own line with the data type and constraints aligned. Primary key and foreign key constraints should be clearly separated from column definitions. Index creation statements that accompany table definitions should be formatted with the index columns clearly visible.

Reporting and Analytics Queries

Business intelligence queries frequently use GROUP BY with multiple aggregate functions, CASE expressions for conditional counting, and date functions for period-over-period comparisons. Formatting these queries reveals the calculation logic that produces each metric. When a stakeholder questions a number in a report, having the formatted query available makes it possible to trace the calculation back to its source data.

Performance Analysis with Formatted SQL

Database performance tuning starts with understanding the query. EXPLAIN ANALYZE output shows how the database engine executes a query, including scan types, join methods, and row estimates. But before you can interpret an execution plan, you need to understand the query itself. Formatting the query first, then running EXPLAIN ANALYZE, creates a clear mental model of what the query should do. You can then compare this expectation against what the execution plan reveals.

Common performance patterns to look for in formatted queries include full table scans (queries without WHERE conditions on indexed columns), nested loop joins on large tables (which may indicate a missing index), and sorting operations on non-indexed columns. The formatted query makes these patterns visible because the relevant clauses are separated and indented.

Another performance consideration is query complexity. A query with five or more joins, multiple subqueries, and complex WHERE conditions may benefit from being split into multiple simpler queries or materialized as a view. The formatted version of the query makes it possible to count these complexity factors and make an informed decision about whether to refactor.

History of SQL Formatting

SQL was originally designed in the 1970s at IBM as a human-readable query language. The original papers used uppercase keywords and lowercase identifiers, a convention that persists today. Early SQL formatting was influenced by the limited screen space of terminals (typically 80 columns wide and 24 rows tall), which encouraged compact formatting.

As database systems grew more complex and queries became longer, the need for formatting tools grew. The first SQL formatters were simple scripts that added line breaks before major keywords. Modern formatters like this one parse the SQL into tokens and apply formatting rules based on the syntactic role of each token, producing more precise and consistent results.

The emergence of version control systems like Git made consistent SQL formatting more important. Inconsistent formatting creates noisy diffs where whitespace changes obscure logical changes. Teams that adopt automated SQL formatting report fewer merge conflicts and more meaningful code review comments on their SQL files.