Formatted SQL will appear here...
Format and beautify SQL queries with token-based parsing, proper indentation for subqueries, CASE/WHEN blocks, JOIN conditions, and customizable formatting options. Supports SELECT, INSERT, UPDATE, DELETE, CREATE TABLE and other common SQL statements.
What is SQL Formatter?
SQL formatting transforms dense, hard-to-read database queries into well-structured, easily scannable code. When queries are written inline in application code, copied from query logs, or generated by ORMs, they often arrive as unformatted blocks of text with no line breaks or consistent capitalization. A token-based SQL formatter parses the query into its component parts — keywords, identifiers, strings, operators, and punctuation — then applies formatting rules that place each clause on its own line, indent nested structures like subqueries and CASE expressions, and align column lists for readability. This approach correctly handles string literals (never uppercasing content inside quotes), preserves comments, and respects function call syntax. Whether you're debugging a slow query from production logs, reviewing a complex analytics query with multiple JOINs, or cleaning up a CREATE TABLE statement, formatted SQL makes the structure immediately visible and errors far easier to spot.
How to Use
- Paste SQL query (minified or unformatted) into the input area
- Click the gear icon to adjust formatting options (indentation, keyword case, comma position)
- Click 'Format SQL' to beautify with proper indentation and structure
- Use sample buttons to test with SELECT, complex, or CREATE TABLE queries
- Copy formatted SQL for your query editor or codebase
Why Use This Tool?
Tips & Best Practices
- Use 'Leading commas' to make version control diffs cleaner when adding columns
- Choose 'Only when multiple columns' for compact single-column SELECTs
- UPPERCASE keywords make structure instantly visible in complex queries
- The formatter preserves string contents — keywords inside quotes are not modified
- Comments (both -- and /* */) are preserved in the output
- Function arguments stay on one line for readability
Frequently Asked Questions
What SQL statements are supported?
SELECT (with JOIN, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT), INSERT INTO ... VALUES, UPDATE ... SET, DELETE FROM, CREATE TABLE (with column definitions and constraints), UNION/UNION ALL, and CTEs (WITH ... AS). Complex analytics queries with multiple JOINs, subqueries, and CASE expressions format correctly.
How does the token-based parser work?
The formatter first tokenizes SQL into keywords, identifiers, strings, numbers, operators, and punctuation. This prevents issues like uppercasing keywords inside string literals or breaking function arguments. Each token type gets appropriate formatting rules applied.
What formatting options are available?
Four options: Indentation size (2 or 4 spaces), Keyword case (UPPERCASE, lowercase, or preserve original), Comma position (trailing or leading), and Newline after SELECT (always or only when multiple columns). These cover the most common SQL style conventions.
How are subqueries formatted?
Subqueries inside parentheses get increased indentation. The opening paren stays on the current line, and the nested SELECT starts on a new indented line. The closing paren returns to the outer indentation level. Multiple levels of nesting are supported.
How are CASE expressions formatted?
CASE starts on the current line. Each WHEN/ELSE appears on a new line with extra indentation. THEN follows WHEN on the same line. END returns to the CASE indentation level. Nested CASE expressions get additional indentation.
Can formatting break my SQL?
No — formatting only changes whitespace and keyword case. The token-based parser preserves all string literals, comments, and identifiers exactly as written. SQL syntax and semantics remain identical. The formatter handles edge cases like escaped quotes and multi-line comments correctly.
Is my SQL query kept private?
Yes. All formatting runs entirely in your browser using client-side JavaScript. Your SQL queries are never sent to any server, never stored, and never logged. The tool works offline once loaded.
When should I NOT use this formatter?
Avoid using this for SQL dialects with non-standard syntax like PostgreSQL's dollar-quoted strings, MySQL's backtick identifiers with special characters, or Oracle's PL/SQL blocks with custom syntax. The formatter handles standard SQL well but may misformat vendor-specific extensions. Also skip it for SQL inside application code where your IDE's built-in formatter already handles formatting.
Real-world Examples
Formatting a query from production database logs
Database slow-query logs often contain unformatted SQL. Format the query to understand its structure and identify optimization opportunities.
select u.id,u.name,o.order_id,o.total from users u left join orders o on u.id=o.user_id where u.status='active' and o.total>100 order by o.total desc limit 10
SELECT
u.id,
u.name,
o.order_id,
o.total
FROM users u
LEFT JOIN orders o
ON u.id = o.user_id
WHERE u.status = 'active'
AND o.total > 100
ORDER BY o.total DESC
LIMIT 10Beautifying a CREATE TABLE statement
Schema definitions are easier to review when each column and constraint is on its own line with proper indentation.
create table users(id serial primary key,name varchar(255) not null,email varchar(255) unique not null,status varchar(50) default 'active',created_at timestamp not null default now())
CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, email VARCHAR(255) UNIQUE NOT NULL, status VARCHAR(50) DEFAULT 'active', created_at TIMESTAMP NOT NULL DEFAULT NOW() )