SQL Dialect:

Indentation:

Keyword Case:

Input SQL

0 characters

Formatted SQL

💡 Features

✅ Format SQL for better readability
✅ Support for 7 SQL dialects (MySQL, PostgreSQL, SQLite, etc.)
✅ Configurable indentation (2/4 spaces or tabs)
✅ Keyword case transformation (UPPER/lower/preserve)
✅ Minify SQL (remove extra whitespace)
✅ Copy formatted output to clipboard

About SQL Formatter - Format & Beautify SQL Queries Online

SQL Formatter is a powerful online tool that formats and beautifies SQL queries for better readability and maintainability. Whether you're working with MySQL, PostgreSQL, SQL Server, Oracle, or SQLite, our formatter supports multiple SQL dialects and provides configurable formatting options. Transform messy, unformatted SQL into clean, well-structured queries with proper indentation, keyword capitalization, and line breaks. Perfect for database developers, DBAs, data analysts, and anyone working with SQL databases.

What is SQL Formatting?

SQL formatting is the process of organizing SQL code into a readable, consistent structure by applying indentation, line breaks, spacing, and capitalization rules. Well-formatted SQL improves code readability, makes debugging easier, facilitates code reviews, and helps teams maintain consistent coding standards. Unlike many programming languages with automated formatters, SQL queries are often written inline or generated dynamically, leading to unreadable one-liners. A SQL formatter takes these compact queries and transforms them into properly structured code with keywords on separate lines, aligned columns, and logical grouping of clauses. This is especially important in database development where complex queries with multiple JOINs, subqueries, and CTEs (Common Table Expressions) can span hundreds of lines. Good formatting makes it easy to spot issues like missing JOIN conditions, incorrect GROUP BY clauses, or inefficient subqueries at a glance.

How to Use This SQL Formatter

1. **Paste Your SQL**: Copy your unformatted SQL query and paste it into the input textarea
2. **Select SQL Dialect**: Choose your database system (MySQL, PostgreSQL, SQL Server, etc.)
3. **Configure Style**: Select indentation (2/4 spaces or tabs) and keyword case (UPPER/lower/preserve)
4. **Click Format**: Press the "Format SQL" button to beautify your query
5. **Review Output**: The formatted SQL appears in the output panel with proper structure
6. **Copy Result**: Use the "Copy" button to copy the formatted SQL to your clipboard
7. **Try Minify**: Use the "Minify" button to compress SQL into a single line (useful for APIs)
8. **Load Sample**: Click "Load Sample" to see an example of formatting in action

SQL Dialects Supported

Our formatter supports 7 major SQL dialects, each with its own syntax quirks and extensions. **Standard SQL** follows ANSI/ISO SQL standards and works for most databases. **MySQL** supports MySQL-specific syntax like LIMIT, backtick identifiers, and MySQL functions. **PostgreSQL** handles PostgreSQL extensions like RETURNING, DISTINCT ON, and dollar-quoted strings. **SQLite** formats SQLite-specific syntax including AUTOINCREMENT and lightweight constraints. **MariaDB** supports MariaDB features which are mostly MySQL-compatible with some extensions. **T-SQL (SQL Server)** handles Microsoft SQL Server syntax including TOP, OFFSET-FETCH, and square bracket identifiers. **PL/SQL (Oracle)** supports Oracle-specific syntax like DUAL table, ROWNUM, and Oracle analytic functions. Choosing the correct dialect ensures that your SQL is formatted according to the conventions and syntax rules of your specific database system, preventing formatting errors with dialect-specific keywords or constructs.

Common SQL Use Cases

**Database Development**: Format complex queries during development for better readability
**Code Reviews**: Share well-formatted SQL in pull requests for easier review
**Documentation**: Include formatted SQL examples in technical documentation
**Debugging**: Format query logs or dynamic SQL to identify issues quickly
**ORM Inspection**: Format queries generated by ORMs (Sequelize, TypeORM, Entity Framework)
**Migration Scripts**: Format schema migration files for version control
**Query Optimization**: Format queries before analyzing execution plans
**Teaching & Training**: Use formatted SQL in tutorials and coding bootcamps
**API Development**: Minify SQL for embedding in API responses or configurations
**Data Analysis**: Format ad-hoc queries in Jupyter notebooks or data science workflows

Formatting Options Explained

Our SQL formatter offers three main configuration options. **Indentation Style** controls how nested clauses are indented: 2 spaces (compact, popular in web development), 4 spaces (traditional, used in enterprise), or tabs (preferred by some teams for accessibility). **Keyword Case** determines how SQL keywords are capitalized: UPPERCASE (most common convention, makes keywords stand out), lowercase (modern style, popular in Python/Ruby communities), or preserve (keeps original casing). **SQL Dialect** affects which syntax rules are applied: different dialects have different reserved keywords, quoting styles (backticks vs square brackets vs double quotes), and clause ordering. For example, MySQL uses LIMIT while SQL Server uses TOP. Choosing the right combination depends on your team's coding standards and database platform. Most teams standardize on UPPERCASE keywords with 2 or 4 spaces indentation.

SQL Formatting Best Practices

**Use Consistent Keyword Case**: Stick to UPPERCASE keywords (SELECT, FROM, WHERE) throughout your codebase
**One Clause Per Line**: Put major clauses (SELECT, FROM, JOIN, WHERE) on separate lines
**Indent Nested Queries**: Indent subqueries and CTEs to show hierarchy
**Align Column Names**: In SELECT, align column names vertically for readability
**Group Related Logic**: Keep related JOINs together, separate WHERE conditions logically
**Use Comments**: Add -- comments to explain complex logic or business rules
**Avoid SELECT ***: List columns explicitly even if formatted, for clarity and performance
**Format Before Commit**: Always format SQL before committing to version control
**Use CTEs Over Subqueries**: CTEs (WITH clauses) are easier to format and read
**Break Long Lines**: Wrap long CASE statements or IN lists across multiple lines

SQL Keywords and Clauses

SQL queries consist of various keywords and clauses organized in a specific order. **SELECT** specifies which columns to retrieve. **FROM** indicates the table(s) to query. **JOIN** combines rows from multiple tables (INNER, LEFT, RIGHT, FULL OUTER). **WHERE** filters rows based on conditions. **GROUP BY** groups rows for aggregation. **HAVING** filters grouped results. **ORDER BY** sorts results. **LIMIT/OFFSET** (or TOP in SQL Server) restricts result count and pagination. **UNION/INTERSECT/EXCEPT** combine multiple queries. **INSERT/UPDATE/DELETE** modify data. **CREATE/ALTER/DROP** manage database objects. Understanding clause order is crucial: SELECT → FROM → JOIN → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT. Formatting highlights this structure by placing each major clause on its own line, making it easy to see the query's logical flow. Subqueries can appear in SELECT, FROM, or WHERE clauses and should be indented to show nesting. Window functions (OVER, PARTITION BY) are formatted to show partitioning and ordering clearly.

SQL Joins Explained

SQL JOINs combine rows from two or more tables based on related columns. **INNER JOIN** returns only matching rows from both tables - most common, filters out non-matches. **LEFT JOIN (LEFT OUTER JOIN)** returns all rows from left table plus matching rows from right table, with NULLs for non-matches. **RIGHT JOIN** (less common) returns all rows from right table plus matching rows from left. **FULL OUTER JOIN** returns all rows from both tables, with NULLs where no match exists. **CROSS JOIN** returns Cartesian product (every combination of rows). **SELF JOIN** joins a table to itself, useful for hierarchical data. Proper formatting makes JOIN conditions clear: put the JOIN keyword and table name on one line, then the ON condition on the next indented line. For multiple JOINs, stack them vertically with consistent indentation. Example formatted JOIN: 'FROM users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN products p ON o.product_id = p.id'. This vertical alignment makes it obvious which tables are involved and how they're related.

Advanced SQL Features

Modern SQL includes powerful features beyond basic SELECT queries. **CTEs (Common Table Expressions)** using WITH clause create temporary named result sets, making complex queries more readable. **Window Functions** (ROW_NUMBER, RANK, LAG, LEAD) perform calculations across row sets without grouping. **Recursive CTEs** handle hierarchical data like org charts or file systems. **CASE Expressions** provide conditional logic similar to if/else. **Subqueries** can appear in SELECT (scalar subquery), FROM (derived table), or WHERE (correlated subquery). **UNION/UNION ALL** combine multiple SELECT results. **EXISTS/NOT EXISTS** check for existence of rows. **Aggregate Functions** (COUNT, SUM, AVG, MAX, MIN) compute across rows. **GROUP BY with ROLLUP/CUBE** create subtotals and grand totals. Formatting these features properly is crucial: indent CTEs, align window function clauses, wrap long CASE expressions, and indent subqueries. Our formatter handles all these constructs, preserving logic while improving readability.

SQL Performance Optimization

While formatting doesn't directly impact performance, readable SQL makes optimization easier. **Execution Plans** are easier to analyze when query structure is clear. **Index Usage** becomes obvious when you see which columns appear in WHERE and JOIN conditions. **Avoiding N+1 Queries** is easier when you can see all data access patterns. **Query Hints** and optimizer directives are more visible in formatted code. **Avoiding SELECT *** encourages explicit column selection, reducing data transfer. **JOIN Order** becomes apparent, allowing you to verify that largest tables aren't joined first. **Subquery vs JOIN** decisions are clearer when both are well-formatted. Performance issues often hide in messy SQL: formatting reveals redundant subqueries, missing indexes, or inefficient JOINs. Tools like EXPLAIN (PostgreSQL/MySQL) or SHOWPLAN (SQL Server) generate execution plans that reference table/column names - formatted SQL makes it easy to match plan output to query structure. Regular formatting + performance analysis should be part of every database development workflow.

SQL in Different Programming Languages

SQL is embedded in almost every programming language, often as strings or query builders. **JavaScript/Node.js** uses template literals, Sequelize, Knex, or TypeORM. **Python** uses string formatting, SQLAlchemy, Django ORM, or raw psycopg2/pymysql queries. **Java** uses JDBC PreparedStatements, Hibernate ORM, or JPA. **C#/.NET** uses ADO.NET, Entity Framework, or Dapper. **PHP** uses PDO, mysqli, or Eloquent (Laravel). **Go** uses database/sql with pgx or go-sql-driver. **Ruby** uses ActiveRecord (Rails) or Sequel. **Rust** uses sqlx or diesel. When writing SQL in code, consider using query builders or ORMs that auto-format, but for raw queries, format them before embedding: use multi-line strings (JavaScript template literals, Python triple quotes, etc.) to preserve formatting. This makes debugging easier since you can copy-paste the formatted query into a SQL client. For dynamic queries, build them in formatted chunks. Example (JavaScript): const query = `SELECT u.id, u.name FROM users u WHERE u.status = $1 ORDER BY u.created_at DESC`; - the formatting survives into the code.

SQL Security: Preventing SQL Injection

SQL injection is a critical security vulnerability where attackers inject malicious SQL into queries. **Never Concatenate User Input** directly into SQL strings - use parameterized queries instead. **Use Prepared Statements** (PDO in PHP, PreparedStatement in Java, query parameters in C#) which separate SQL structure from data. **Validate Input**: Even with prepared statements, validate data types and ranges. **Escape Special Characters** if you must build dynamic SQL (not recommended). **Principle of Least Privilege**: Database users should have minimum necessary permissions. **Avoid Dynamic Column/Table Names**: If unavoidable, use whitelists. **Use ORMs Safely**: ORMs prevent injection when used correctly, but raw queries within ORMs must still use parameters. Example vulnerable code: `query = 'SELECT * FROM users WHERE id = ' + user_id` (NEVER DO THIS). Safe version: `query = 'SELECT * FROM users WHERE id = ?'` with parameter binding. Formatting SQL makes injection attempts more visible during code review - look for suspicious concatenation or unescaped quotes. Tools like SQLMap can test for injection vulnerabilities. Always use static analysis (linters) and security scanners.

Frequently Asked Questions

What is the difference between formatting and minifying SQL?

Formatting adds whitespace, line breaks, and indentation to make SQL readable for humans. It expands queries vertically with one clause per line. Minifying does the opposite - it removes all unnecessary whitespace, line breaks, and comments to create the most compact representation. Minified SQL is useful for API payloads, configuration files, or when storing queries in databases where space is limited. However, minified SQL is nearly impossible to read or debug. Use formatting for development, code reviews, and documentation; use minifying only for production deployment where size matters.

Why are my keywords not capitalizing even though I selected UPPERCASE?

The formatter only capitalizes recognized SQL keywords (SELECT, FROM, WHERE, JOIN, etc.). If you have column names, table names, or variables that look like keywords but aren't, they won't be capitalized. Also, strings inside quotes are never modified. If specific keywords aren't capitalizing, ensure you've selected the correct SQL dialect - different databases have different reserved words. For example, 'LIMIT' is MySQL/PostgreSQL but 'TOP' is SQL Server. If you still see issues, the formatter may not recognize certain dialect-specific extensions. You can manually capitalize those or file an issue with the sql-formatter library maintainers.

Can I format stored procedures, triggers, or PL/SQL blocks?

Yes! Our formatter supports complex SQL constructs including stored procedures, functions, triggers, and PL/SQL blocks. Select the 'PL/SQL (Oracle)' dialect for Oracle procedures or 'T-SQL (SQL Server)' for SQL Server stored procedures. The formatter will properly indent BEGIN/END blocks, IF/ELSE statements, WHILE loops, and DECLARE sections. However, extremely complex procedural code with embedded dynamic SQL or unusual syntax may not format perfectly. For production stored procedures, review the formatted output carefully and consider using database-specific formatting tools (Oracle SQL Developer, SQL Server Management Studio) for complex cases.

Does formatting my SQL affect query performance or execution?

No, formatting has zero impact on query performance or execution. The database engine parses and optimizes the query structure, not the whitespace or formatting. 'SELECT * FROM users' and a formatted multi-line SELECT produce identical execution plans. The only minor exception is query size: extremely long minified queries might parse slightly faster than formatted ones, but the difference is negligible (microseconds). In fact, well-formatted SQL often leads to better performance indirectly because developers can spot optimization opportunities (missing indexes, inefficient JOINs, redundant subqueries) more easily. Always prioritize readability - the time saved in debugging and optimization far outweighs any theoretical parsing difference.

What is the standard SQL formatting convention?

While there's no universal standard, most SQL style guides agree on: (1) UPPERCASE keywords (SELECT, FROM, WHERE), (2) lowercase table/column names or follow database conventions, (3) one major clause per line (SELECT on one line, FROM on next), (4) indent subqueries and JOINs (2 or 4 spaces), (5) align column lists vertically in SELECT, (6) commas before column names (leading commas) or after (trailing commas) - teams are split on this, (7) use CTEs instead of nested subqueries when possible. Popular style guides include SQL Style Guide by Simon Holywell, Mozilla SQL Style Guide, and team-specific guides at major companies. Choose a style that works for your team and enforce it consistently with a formatter.

Can I save my formatting preferences?

Currently, formatting preferences (dialect, indentation, keyword case) are not persisted across sessions. You need to select them each time you load the page. However, your browser may remember the last selected values temporarily. For consistent formatting across a team, consider documenting your standard settings (e.g., 'MySQL dialect, 2 spaces, UPPERCASE keywords') in your project README or style guide. In future versions, we may add the ability to save preferences to localStorage or user accounts. For now, most formatting can be standardized by choosing dialect and letting defaults (uppercase keywords, 2-space indent) handle the rest.

How do I format SQL in my code editor (VS Code, IntelliJ)?

Most modern IDEs have SQL formatting built-in or via extensions. **VS Code**: Install 'SQL Formatter' extension by Tobias Salzmann or 'vscode-sql-formatter'. Configure formatting rules in settings.json. **IntelliJ/DataGrip**: Built-in SQL formatter under Code → Reformat Code (Ctrl+Alt+L). Customize in Settings → Editor → Code Style → SQL. **Sublime Text**: Install 'SQLFormat' package. **Vim**: Use sqlformat command-line tool with plugins. **Emacs**: sql-mode with pgFormatter. For consistent team formatting, use a command-line tool like pgFormatter or sql-formatter (Node package) and run it as a pre-commit hook (Husky, Git hooks). This ensures all SQL is formatted before it reaches code review, similar to Prettier for JavaScript or Black for Python.

What are CTEs and why should I use them?

CTEs (Common Table Expressions) are temporary named result sets defined using WITH clauses. They replace nested subqueries with readable, top-down logic. Example: 'WITH active_users AS (SELECT * FROM users WHERE status = 'active') SELECT u.name, COUNT(o.id) FROM active_users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.name'. Benefits: (1) Readability - named CTEs are self-documenting, (2) Reusability - reference the same CTE multiple times, (3) Debugging - test each CTE independently, (4) Recursion - recursive CTEs can query hierarchical data, (5) Performance - some databases optimize CTEs better than subqueries. Use CTEs for complex queries with multiple subqueries, or when you need to reference a subquery result more than once. Formatting CTEs is easy: put each CTE on its own line with proper indentation, making query structure obvious at a glance.

Why does my formatted SQL have more lines than the original?

That's expected and intentional! Formatting expands compact, hard-to-read one-liners into multi-line, well-structured queries. A query like 'SELECT u.id,u.name,u.email FROM users u JOIN orders o ON u.id=o.user_id WHERE u.status='active'' might expand to 10+ lines with proper formatting. Each clause (SELECT, FROM, JOIN, WHERE) gets its own line, column lists are expanded vertically, and nested elements are indented. The goal isn't brevity - it's clarity. Longer formatted SQL is easier to read, review, debug, and maintain. Think of it like code formatting in any language: nobody writes JavaScript or Python on one line. If line count is a concern (e.g., for logs or APIs), use the Minify option to compress the SQL back to a single line after validation.

Can I format SQL with syntax errors?

The formatter will attempt to format SQL even with syntax errors, but results may be unpredictable. If the error is minor (missing semicolon, typo in table name), formatting usually succeeds and may even help you spot the error. However, if the SQL is severely malformed (unmatched parentheses, truncated query, invalid keywords), the formatter will fail and display an error message. Use the error message to identify the issue: look for unexpected tokens, missing keywords, or incorrect clause order. Fix the syntax error first, then format. Some teams actually use formatters as a syntax checker - if formatting fails, you know something's wrong. For complex validation, use database-specific tools like mysql -e 'CHECK SYNTAX' or pg_query validators that provide detailed error messages with line numbers.

SQL Formatter