SQL Formatter - Free Online Tool | PivaBox

Format and beautify SQL queries with keyword capitalization and indentation

SQL Formatter & Beautifier — Format SQL Queries with Keyword Capitalization, Intelligent Indentation, and Dialect-Specific Syntax for MySQL, PostgreSQL, SQLite, and T-SQL

Paste your SQL query into the input textarea — the tool accepts everything from single-line SELECT statements to multi-hundred-line stored procedures with CTEs, subqueries, window functions, and complex JOIN hierarchies. SQL (Structured Query Language) is the universal language of databases, but SQL formatting is notoriously inconsistent — queries copied from database logs, ORM-generated SQL, or legacy codebases are often compressed into single lines or indented with chaotic spacing. Poorly formatted SQL is not just aesthetically unpleasant — it's harder to debug, harder to optimize (query structure becomes invisible), and harder to review for security issues (SQL injection points hide in dense, unformatted queries).
Select your SQL dialect from the dropdown to ensure correct keyword recognition and formatting. Different SQL dialects have different keyword sets and syntax variations: Standard SQL (ANSI/ISO) — the baseline that all dialects extend; MySQL — includes MySQL-specific keywords (LIMIT, AUTO_INCREMENT, ENGINE) and backtick identifier quoting; PostgreSQL — supports RETURNING, ILIKE, JSONB operators, and dollar-quoted strings; SQLite — the embedded database dialect with REPLACE and special pragma support; T-SQL (Transact-SQL) — Microsoft SQL Server's dialect with TOP, MERGE, bracket identifier quoting, and stored procedure syntax. Selecting the correct dialect ensures that dialect-specific keywords are properly capitalized and formatted.
Click Format to beautify your SQL. The formatter applies consistent styling: keyword capitalization — all SQL keywords (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, INSERT INTO, CREATE TABLE) are uppercased for visual prominence; intelligent indentation — each clause starts on a new line, subqueries are indented one level deeper, JOIN conditions align under their ON clauses, CASE expressions indent WHEN/THEN/ELSE branches; column alignment — multi-column SELECT lists align each column on its own line; parenthesis matching — nested function calls and subexpressions maintain proper bracket pairing with readable indentation. The formatter handles complex patterns correctly: CTEs (WITH ... AS), window functions (ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)), multi-table JOINs with nested conditions, UNION/INTERSECT/EXCEPT queries, and deeply nested subqueries. All formatting uses the sql-formatter library running entirely in your browser — your database queries, which may contain table schemas revealing business logic, never leave your device.

Frequently Asked Questions

Why does SQL formatting matter beyond aesthetics — can't the database just execute unformatted SQL the same way?

The database engine indeed executes unformatted SQL identically to formatted SQL — the query optimizer doesn't care about whitespace. However, formatted SQL has substantial practical benefits: (1) Query optimization — a formatted query reveals its logical structure. You can see at a glance whether a JOIN is INNER or LEFT, which columns are indexed in the WHERE clause, and whether a subquery could be rewritten as a JOIN. Trying to optimize a 200-line single-line query is nearly impossible because the clause structure is invisible. (2) Debugging — when a query returns unexpected results or a syntax error, finding the problematic clause in formatted SQL takes seconds; in compressed SQL, it takes much longer. (3) SQL injection prevention — formatted SQL makes it easier to identify where user input is concatenated into queries (a security anti-pattern); dynamic table/column names and string concatenation stand out visually. (4) Code review — database schema changes and query modifications in pull requests are reviewable when formatted; single-line SQL diffs are essentially unreviewable. (5) Documentation and knowledge sharing — formatted queries in documentation, runbooks, and team wikis are readable by junior developers and non-SQL stakeholders. The PivaBox SQL Formatter provides instant formatting for all these benefits — entirely private and browser-side.

How does the formatter handle different SQL dialect quoting conventions (backticks, double quotes, square brackets)?

SQL identifier quoting is dialect-specific, and the formatter preserves the quoting style of the selected dialect correctly. MySQL uses backticks (<code>`table_name`</code>) for identifiers and single quotes for string literals — the formatter leaves backtick-quoted identifiers untouched while uppercasing keywords. PostgreSQL uses double quotes (<code>"Table Name"</code>) for identifiers (making them case-sensitive) and single quotes for literals; the formatter respects the SQL standard double-quote convention. T-SQL (SQL Server) uses square brackets (<code>[Table Name]</code>) as its primary identifier quoting mechanism, though double quotes work with <code>QUOTED_IDENTIFIER ON</code> — the formatter handles both. SQLite accepts backticks, double quotes, and square brackets interchangeably for identifiers (for compatibility), though double quotes are the SQL standard. The formatter also correctly handles: string literals — single quotes with escaped quotes (<code>'It''s'</code> for the string It's), dollar-quoted strings in PostgreSQL (<code>$SELECT * FROM users$</code> — used for function bodies and dynamic SQL), and escape sequences in string literals. The PivaBox SQL Formatter preserves your identifier casing and quoting while normalizing only the formatting structure.

What's the best SQL formatting style, and does this formatter follow a specific style guide?

There's no universally accepted SQL style guide (unlike languages like Python with PEP 8 or Go with gofmt), but several influential guides have converged on similar conventions. This formatter follows principles aligned with Joe Celko's SQL Programming Style and Simon Holywell's SQL Style Guide: (1) Keywords UPPERCASE — improves visual scanning; SQL keywords stand out from table/column identifiers (typically lowercase). (2) Each major clause on a new line — SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT each start a new line; makes clause structure immediately visible. (3) Indentation for logical hierarchy — subqueries, JOIN conditions, and CASE branches indent to show nesting. (4) One column per line in SELECT lists — especially for queries with 5+ columns or columns with expressions/aliases. (5) Align JOIN conditions — the ON clause of a JOIN is indented under the JOIN keyword. (6) Commas at the beginning of lines — some styles prefer leading commas (<code>, column2</code> rather than <code>column1,</code>) because they're easier to comment out and add/remove; this formatter uses the trailing-comma convention (more widely used) but you can manually adjust after formatting. For team consistency, pick a style guide, configure your formatter to match, and enforce it via CI/CD (SQLFluff for linting, SQLFormat for formatting). The PivaBox formatter provides a clean, readable baseline that you can further customize manually.