Options
SELECT
u.id,
u.name,
count(o.id) AS order_count
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.created_at > '2025-01-01'
AND u.status IN ('active', 'trial')
GROUP BY
u.id,
u.name
HAVING
count(o.id) > 0
ORDER BY
order_count DESC
LIMIT
100;sql-formatter library. Zero HTTP requests during formatting — verify in DevTools' Network tab.About SQL Formatter
A SQL formatter takes minified or unstructured SQL and applies consistent indentation, keyword casing, and line breaks for readability. Dialect-aware — different SQL flavors (PostgreSQL, MySQL, SQLite, T-SQL, BigQuery, Snowflake, Redshift, DB2, MariaDB) have subtly different syntax (e.g., `LIMIT` vs `TOP`, dollar-quoted strings, backtick identifiers), so the formatter must recognize the dialect to apply correct rules.
Why use a SQL Formatter?
Long SQL queries are unreadable without formatting — nested CTEs, JOINs with many conditions, and WHERE clauses with multiple AND/OR branches become impossible to follow. Code reviews, debugging, and team handoffs all benefit from consistent SQL formatting. Many codebases enforce SQL style via pre-commit hooks; pasting into this tool is the manual equivalent.
Who is it for?
Backend developers writing queries against PostgreSQL/MySQL/SQLite, data analysts working with SQL on BigQuery/Snowflake/Redshift, DBAs reviewing slow query plans, anyone learning SQL who wants to see queries in canonical form, and teams establishing SQL style guidelines.
How to use the tool
Paste your SQL into the input area
Select your dialect (PostgreSQL, MySQL, SQLite, T-SQL, BigQuery, Snowflake, MariaDB, Redshift, DB2, or standard SQL)
Choose options: keyword case (UPPER/lower), indent size (2 or 4 spaces), comma position
View the formatted output with proper line breaks and indentation
Copy the result for use in your codebase, query editor, or documentation
Frequently Asked Questions
How do I format SQL queries online?
Paste your SQL into the input area and select the dialect (PostgreSQL, MySQL, SQLite, T-SQL, BigQuery, etc.). The formatter applies indentation, line breaks, and keyword casing per the dialect's conventions. Output appears in real-time. Runs entirely in your browser via the `sql-formatter` library (popular Node.js package). Your SQL never leaves the device — verify in DevTools' Network tab: zero HTTP requests during formatting. Safe for proprietary queries containing internal schemas or business logic.
Why does the formatter need to know my SQL dialect?
SQL has many dialects with subtle syntax differences. Examples: **PostgreSQL** uses dollar-quoted strings (`$$...$$`) and `LIMIT n OFFSET m`. **MySQL/MariaDB** uses backtick identifiers (`` `col` ``) and `LIMIT m, n` shorthand. **T-SQL (SQL Server)** uses bracketed identifiers (`[col]`) and `TOP n` instead of LIMIT. **BigQuery** has standard SQL mode vs legacy SQL with very different syntax. **SQLite** is mostly standard but lacks some features. The formatter parses your SQL per the dialect's rules — picking the wrong dialect may misformat dialect-specific syntax. When in doubt, choose 'standard SQL' (ANSI SQL — works for the common-subset).
Is my SQL sent to a server?
No — formatting runs entirely in your browser via the `sql-formatter` JavaScript library. Your queries never reach a server, never get logged. Verify in DevTools' Network tab: zero HTTP requests during formatting. Safe for proprietary queries with sensitive schema names, business logic, or PII column references. For sustained team usage, install `sql-formatter` locally (npm or VS Code extension) — same library, no web tool involved.
What's the difference between formatting and minifying SQL?
Formatting (this tool) adds whitespace and line breaks for human readability. Minifying removes whitespace to reduce query size — rarely useful for SQL (queries are usually small, and the SQL parser doesn't care about whitespace). The exception: SQL embedded as strings in code (e.g., a multi-line query in a Python or JavaScript string), where compact one-line form saves visual space. For embedded queries, prefer template literals + format on display (some IDEs format inline). For ad-hoc query writing, format for readability.
Should I use UPPERCASE or lowercase keywords?
Stylistic choice. **UPPERCASE keywords** (`SELECT`, `FROM`, `WHERE`): traditional convention; easier to scan because keywords stand out from identifiers. Common in older codebases, documentation, and SQL textbooks. **lowercase keywords** (`select`, `from`, `where`): modern convention in some style guides (e.g., GitLab's, dbt's). Argument: keywords are part of the language; uppercase is shouting; lowercase is friendlier. Either is fine — pick one and apply consistently across your team. Most formatters default to UPPERCASE; switch via the option.
How does the formatter handle complex queries with CTEs and subqueries?
Common Table Expressions (CTEs — `WITH ... AS (...)`) and subqueries are indented to show nesting. Each CTE is on its own block; subqueries in JOIN/WHERE clauses are indented one level deeper than their parent. For very deeply nested queries (3+ CTE levels, or subqueries within subqueries within subqueries), the indentation grows wide; refactor into multiple CTEs for readability. The formatter helps reveal complex structure; it doesn't fix bad query design — for that, use `EXPLAIN ANALYZE` and refactor.
Does this validate or check the SQL?
No — formatting only adjusts whitespace. The formatter doesn't validate that columns exist, that the syntax is correct for your database, or that the query is efficient. For validation: connect to your database with a query tool (psql, mysql, DBeaver, TablePlus) and run `EXPLAIN <query>` (postgres) or `EXPLAIN ANALYZE <query>` to see the plan without executing. For static analysis (catching `SELECT *`, missing indexes hints), use tools like `sqlfluff` (lint), `pg_qualstats` (Postgres), or the database's own query advisor.
What about dialect-specific edge cases (PostgreSQL arrays, MySQL backticks)?
The `sql-formatter` library handles common dialect features: PostgreSQL JSON operators (`->`, `->>`), array literals (`ARRAY[...]`), dollar-quoted strings (`$$...$$`); MySQL backticks (`` `col` ``); T-SQL square brackets (`[col]`); BigQuery STRUCT/ARRAY types. Edge cases that occasionally trip formatters: deeply-nested arrays, vendor extensions (Postgres extensions like PostGIS spatial operators), and very long string literals containing SQL-like keywords. If the formatter produces output that doesn't parse in your database, file an issue with the `sql-formatter` library — the maintainers actively fix dialect bugs.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.