SQL Query Formatter

All processing happens locally in your browser. No SQL data is ever sent to a server.
SQL Input
1 line
1

Enter SQL and click Format & Analyze to see results

Multi-Dialect Formatting

Beautiful formatting for MySQL, PostgreSQL, T-SQL, Oracle, and SQLite with configurable indentation and keyword case.

Human Explanation

Understand complex queries with step-by-step breakdowns in logical execution order — no AI required.

Risk & Performance

Catch dangerous queries (DELETE without WHERE) and performance issues (SELECT *, leading wildcard) before they hit production.

About the SQL Suite

The SQL Suite formats, validates, and beautifies SQL across PostgreSQL, MySQL, SQLite, MS SQL Server, BigQuery, Snowflake, and Redshift dialects — entirely in your browser via the `sql-formatter` and `node-sql-parser` libraries. Paste a query (your ORM-generated mess, an audit-log entry, a vendor support snippet) and get back idiomatic indentation, keyword case, and aligned column lists. The validator surfaces syntax errors with line and column hints. Queries never leave the page, so production-shape SQL with real schema names is safe to paste.

Updated: May 8, 2026

How to use the SQL suite

  • Paste your SQL into the input area. The tool tries to auto-detect the dialect from keywords (`LIMIT` vs `TOP`, `LATERAL` vs `CROSS APPLY`, identifier quoting style); override the auto-detection by selecting from the dialect dropdown.
  • Click Format to apply the dialect-aware pretty-printer. Indentation defaults to 2 spaces and can be set to tabs or 4 spaces.
  • Click Minify to strip comments and collapse whitespace — useful when embedding a query in a one-liner test or a JSON config.
  • Click Validate to parse the query through node-sql-parser and surface syntax errors with line and column references. The validator handles SELECT, INSERT, UPDATE, DELETE, CREATE / DROP / ALTER, and most CTE patterns.
  • Use the Share button to encode the query into a URL with lz-string compression — convenient for filing reproducible SQL bug reports in tickets.

Common use cases

  • Code review prep. Paste an unformatted SQL diff so reviewers can read the actual query structure instead of the original 200-character single-line ORM output.
  • Debugging slow-query logs. Most database slow-query logs emit minified SQL with parameters interpolated. Format it here to see the JOIN graph, subqueries, and WHERE clause structure at a glance.
  • ORM-generated SQL inspection. SQLAlchemy `echo=True`, ActiveRecord `to_sql`, Prisma logs, and the Spring Data Hibernate dialect all output one-liner SQL — formatting reveals what your ORM is actually asking the database to do.
  • Ad-hoc query authoring. Sketch a query, format it as you go, copy into a database client (psql, DBeaver, DataGrip) for execution.
  • Embedding SQL in documentation. Generate readable SQL for ADRs, runbooks, README snippets — a formatted query in markdown is dramatically more reviewable than a minified blob.

Privacy and security

Formatting and validation run via `sql-formatter` and `node-sql-parser` bundled into the page — both pure JavaScript, no network. Your query, including production table names, column names, and inlined parameter values, stays in your browser. URL sync only happens when you click Share, and that uses lz-string compression so the URL is opaque to casual observers (still avoid posting links containing real customer data to public channels).

Tips and pitfalls

  • Dialect auto-detection has limits. PostgreSQL `LATERAL` and SQL Server `CROSS APPLY` are functionally similar but parse differently; `RETURNING` is PostgreSQL/Oracle/SQLite, not MySQL/SQL Server; `OFFSET ... FETCH FIRST` is standard, `LIMIT n` is dialect-specific. When the formatter produces unexpected output, set the dialect explicitly.
  • Comments are preserved on Format. `-- single-line` and `/* block */` comments survive formatting — useful for keeping inline review notes inside the query.
  • CTEs format cleanly. Common Table Expressions (`WITH foo AS (...)`) get aligned indentation and column-list breaks; nested CTEs are still readable past 3-4 levels.
  • Identifier quoting varies. Backticks (`` `table` ``) for MySQL, double quotes (`"table"`) for PostgreSQL/SQL standard, square brackets (`[table]`) for SQL Server. The formatter preserves the original quoting style.
  • Parameter placeholders differ. `?` (MySQL/SQLite/JDBC), `$1, $2, ...` (PostgreSQL), `:name` (Oracle/Hibernate), `@name` (SQL Server / .NET). The validator accepts all of them; check that the dialect setting matches the placeholder convention.

Frequently Asked Questions

Which SQL dialects are supported?
PostgreSQL, MySQL, SQLite, MS SQL Server (T-SQL), BigQuery, Snowflake, Redshift, MariaDB, DB2, and ANSI SQL standard. Auto-detection covers the most common keyword and quoting differences; for ambiguous cases, set the dialect explicitly.
Does it preserve comments?
Yes. Both `-- single-line` and `/* block */` comments survive the formatter. Inline review notes, license headers, and `EXPLAIN`-output annotations stay intact.
How are CTEs formatted?
WITH clauses get their own indentation level; column lists inside the CTE wrap at the comma boundary. Nested CTEs (a `WITH` inside another CTE body) format cleanly through 3-4 nesting levels; deeper nesting becomes hard to read regardless of formatter — consider refactoring to subqueries or temporary tables.
Can I validate syntax beyond just formatting?
Yes — click Validate. The parser (node-sql-parser) catches missing keywords, unbalanced parentheses, mistyped statement structure. It does not check semantics: an invalid table name, a column reference to a column that does not exist, or a type mismatch will pass syntax validation and only fail at execution time.
Does it format DDL statements (CREATE / ALTER / DROP)?
Yes — schema migrations format the same way as queries. CREATE TABLE column definitions get aligned data types and constraints; CREATE INDEX clauses get proper line breaks; ALTER TABLE chains stay readable.
How is this different from sqlfluff?
sqlfluff is a full SQL linter — it enforces project-specific style rules (capitalization, alias requirements, JOIN ordering, etc.). This tool is a formatter — it produces idiomatic dialect-aware indentation but does not enforce a custom rule set. Use this for ad-hoc cleanup, sqlfluff for CI lint enforcement.
Are stored procedures supported?
Partially. Procedure bodies that contain only standard SQL format cleanly; procedure bodies with PL/pgSQL, T-SQL, or PL/SQL control-flow constructs (BEGIN ... END, IF / WHILE, exception blocks) format as one statement and may not pretty-print individual control structures.
Is multi-statement SQL handled?
Yes. Statements separated by semicolons are formatted independently and re-joined with consistent spacing. Useful when you have a setup-query / actual-query pair.
Is the input ever uploaded?
Never. Both formatting (sql-formatter) and parsing (node-sql-parser) run as compiled-to-JavaScript libraries inside your browser tab. The Share button is opt-in and uses lz-string compression to encode the input into the URL fragment.