SQL Formatter & Minifier

SQL Formatter - Format, Minify and Lint Queries Across 15 Dialects

A powerful online SQL formatter, beautifier and safe minifier that supports 15 dialects — Standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, T-SQL (SQL Server), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark SQL, Trino/Presto, Hive and N1QL. Features syntax highlighting, uppercase keywords, customizable indentation, string- and comment-aware minification that never corrupts your data, and a built-in Safety Check that flags UPDATE/DELETE statements with no WHERE clause and destructive TRUNCATE/DROP commands before you run them. Perfect for database developers, DBAs, and backend engineers reviewing migration or maintenance scripts.

What is the standard SQL formatting style?

There is no single official standard, but the most widely adopted convention follows the Joe Celko style (from SQL for Smarties): keywords UPPERCASE, identifiers lowercase or snake_case, one clause per line (SELECT, FROM, WHERE, etc.), columns indented under SELECT, and joins aligned under FROM. Modern tools like sqlfluff, sql-formatter, and pgFormatter implement variations. The ISO/IEC 9075 SQL standard itself only defines syntax and semantics, not style. Each vendor's documentation suggests style guidelines: PostgreSQL Wiki has a code style page, and SQL Server's T-SQL has guides from Microsoft Press. Consistency within a team matters more than the specific style chosen.

Why use UPPERCASE for SQL keywords?

Uppercase keywords (SELECT, FROM, WHERE, JOIN) visually separate SQL syntax from user-defined identifiers (table and column names), making queries scannable at a glance. The convention originated in 1970s mainframe systems where punch cards used all-caps anyway. Modern SQL parsers are case-insensitive for keywords per the ISO 9075 standard, so `select` works identically to `SELECT`. Some teams now prefer lowercase keywords for typing speed and modern aesthetics — the Carbon (IBM) and Stripe API documentation use lowercase. Tools like sqlfluff allow either with the `--rules L030` config. The choice is purely stylistic; pick one and apply consistently.

How should JOINs be formatted for readability?

Each JOIN belongs on its own line, with the ON clause indented or on the next line. Modern style aligns JOINs under FROM and groups conditions vertically:
```
SELECT u.name, o.total
FROM users AS u
JOIN orders AS o ON o.user_id = u.id
LEFT JOIN profiles AS p ON p.user_id = u.id
WHERE o.created_at > '2024-01-01';
```
Explicit JOIN syntax (the ANSI SQL-92 standard) is preferred over the implicit comma-separated FROM clause because it cleanly separates join conditions from filters and prevents accidental Cartesian products. PostgreSQL EXPLAIN ANALYZE plans optimize both forms identically, but the readability difference compounds in queries with 5+ tables.

What is SQL minification and is it worth it?

SQL minification strips whitespace, comments, and unnecessary line breaks to reduce query string size. Useful when embedding SQL in JavaScript/TypeScript application code that ships to clients, in URL parameters for analytics tools, or in JSON payloads where every byte matters. Tools like `sql-minifier-cli` and `sqlmin` handle this. Caveats: minified SQL is hard to debug and review, and most database servers parse it identically — there is no runtime performance gain from minification. Modern build systems (Vite, Webpack) often minify embedded SQL automatically. Keep source SQL formatted for humans, minify only at build time for production deployment.

How do I prevent SQL injection in formatted queries?

Always use parameterized queries (prepared statements) instead of string concatenation: `SELECT * FROM users WHERE id = $1` with `$1` bound as a parameter, never `SELECT * FROM users WHERE id = ' + userId`. OWASP SQL Injection Prevention Cheat Sheet (2023) and CWE-89 list this as the primary defense. Every modern language SDK supports this: psycopg's `cursor.execute(sql, (id,))`, JDBC's `PreparedStatement.setInt(1, id)`, Node.js pg's `client.query(text, values)`. Formatting style has no security impact, but never include user input directly in SQL strings. Stored procedures and ORMs add additional layers of defense, but proper parameterization is the foundation.

What are Common Table Expressions (CTEs) and how do I format them?

CTEs are named subqueries defined with the WITH keyword, introduced in ISO SQL:1999 and supported by PostgreSQL, MySQL 8.0+, SQL Server, and Oracle. They improve readability by breaking complex queries into named, sequential steps. Format with each CTE on its own block, separated by blank lines:
```
WITH active_users AS (
SELECT id, name FROM users WHERE last_login > NOW() - INTERVAL '30 days'
),
order_totals AS (
SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id
)
SELECT u.name, COALESCE(o.total, 0) AS total
FROM active_users u
LEFT JOIN order_totals o ON o.user_id = u.id;
```
Recursive CTEs use `WITH RECURSIVE` and require careful termination conditions to avoid infinite loops.

Should table and column names use snake_case or PascalCase?

Most database conventions favor snake_case (`user_id`, `created_at`) because all major engines convert unquoted identifiers to lowercase or uppercase internally, making case mixing fragile. PostgreSQL converts to lowercase; Oracle and DB2 to uppercase. PascalCase or camelCase identifiers require double-quoting (`"UserId"`) to preserve case, which is verbose and error-prone. snake_case is the de facto standard in PostgreSQL, MySQL, and SQLite ecosystems. PascalCase is more common in SQL Server (T-SQL), where the engine preserves case in metadata. ORMs like Hibernate and Sequelize provide automatic case conversion (camelCase in code, snake_case in DB) via column-name mappers.

Can it format BigQuery, Snowflake or T-SQL specifically?

Yes. The Dialect dropdown supports 15 grammars and each changes how the formatter treats keywords, operators, and quoting. Pick **bigquery** to handle backtick-quoted `project.dataset.table` identifiers, array/struct syntax, and STANDARD SQL functions; **snowflake** for its `::` cast operator, semi-structured `:` path access, and FLATTEN; **tsql** for SQL Server's `[bracketed]` identifiers, TOP, and `@variables`; **postgresql** for `$1` placeholders, `::type` casts, and dollar-quoted strings. Also supported: MySQL, MariaDB, SQLite, Oracle PL/SQL, Redshift, DB2, Spark SQL, Trino/Presto, Hive, and N1QL (Couchbase). If you pick the wrong dialect the output is still valid but may not align engine-specific syntax ideally, so match the dropdown to your target database for the cleanest result.

Does Minify keep my string data intact?

Yes. The minifier is tokenizer-based: it walks the query and skips over single-quoted, double-quoted, and backtick-quoted literals as well as `--` and `/* */` comments, collapsing whitespace and stripping comments ONLY in the surrounding code regions. That means a value like `'John Doe'` keeps its double space, `'50% -- off'` is not truncated at the `--`, and `'a/*b*/c'` is preserved verbatim. Earlier naive minifiers that run a blanket `\s+` replace silently change query semantics — this tool does not. Run Minify or Format and the **Safety Check** badge above the output also tells you how many statements were parsed, so you can confirm the tool read your script the way you expected.

What tools format SQL automatically?

Top tools in 2025: **sqlfluff** (Python, multi-dialect, opinionated, used by dbt) — most popular, lints and fixes; **pg_format** (Perl, PostgreSQL focus, fast); **sql-formatter** (JavaScript, multi-dialect); **sqlfmt** (from Tylerb, Go-based, opinionated like Black); **Poor SQL** (online); and IDE plugins for VSCode (SQLTools), DataGrip, and SQL Server Management Studio. dbt's adoption of sqlfluff has standardized SQL style in the analytics community. CI integration is straightforward: `sqlfluff lint models/` and `sqlfluff fix --force models/` in your GitHub Actions or GitLab CI before merging. Configure dialect in `.sqlfluff` to match your database (postgres, snowflake, bigquery, mysql, etc.).

Key Features

• Format SQL with customizable indentation
• Uppercase keywords option for better readability
• Safe minify that preserves string literals and comment markers inside quotes
• Safety Check lints for UPDATE/DELETE with no WHERE and TRUNCATE/DROP
• Statement counter for multi-query scripts
• Syntax highlighting for keywords, functions, strings, numbers
• Real-time statistics
• Copy/Download/Upload support
• Dark mode
• 15 dialects: MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark, Trino/Presto, Hive, N1QL
• 100% client-side - no SQL execution
• Mobile-friendly