Skip to content
SQL

Multi-dialect SQL formatter

Format SQL queries across 13 different dialects: MySQL, MariaDB, PostgreSQL, SQLite, MS SQL Server (T-SQL), BigQuery, Snowflake, Redshift, Spark SQL, Trino/Presto, DB2, Oracle PL/SQL and standard SQL. Configurable indent, keyword case (classic UPPERCASE, modern lowercase or preserve), minify mode to embed the query in a code string or a single-line log.

How to use the formatter

  1. 1

    Pick the dialect

    Default MySQL. For other DBs use the specific dialect: PostgreSQL handles ARRAY, JSON, RETURNING; MS SQL T-SQL handles TOP, OUTPUT, CROSS APPLY; BigQuery handles MERGE, EXCEPT-clause specifics. The formatter respects the chosen dialect's grammar.

  2. 2

    Configure keyword case

    lowercase: SELECT, FROM, WHERE -> select, from, where (modern convention default). UPPERCASE: 90s classic style, still preferred by many DBAs. preserve: keep the original case.

  3. 3

    Indent

    2 spaces (default JS/Node convention), 4 spaces (Python/Java/classic SQL), Tab (vim/.editorconfig). Output always normalized to a consistent choice.

  4. 4

    Minify

    For queries to embed in code strings or logs: minify strips comments (-- and /* */), collapses whitespace to single space, trims. Output in single line.

Serious multi-dialect and operational privacy

Dialect-specific grammars. Many online formatters fall back to a generic ANSI SQL parser that doesn't reflect operational reality: PL/SQL stored procedures use BEGIN/EXCEPTION/END the standard does not know, BigQuery uses STRUCT, ARRAY_AGG, EXCEPT with custom parsing rules, T-SQL adds TOP, OUTPUT, CROSS APPLY, and MySQL stored procedure delimiters change the batch grammar. The formatter here uses a dedicated grammar for each of the 13 supported dialects, including specific reserved words and non-standard constructs.

Operational privacy. SQL queries are often confidential: they contain internal table names, business schema, sometimes real values in WHERE clauses (customer emails, internal identifiers). Uploading them to a website to get a pretty-print is a documented anti-pattern for production DB operators. Here the formatting happens directly in the browser: the query does not transit through third-party backends.

Placeholder recognition. Parameterized queries are treated as opaque tokens and preserved as-is in the output: works for ? (MySQL, SQLite), $1 (PostgreSQL), :name (Oracle, MySQL bind), @name (T-SQL). Useful for copying the query out of an application log, formatting for readability, and re-running it without first having to substitute the parameters.

Glossary

Technical terms used on this page, briefly explained.

SQL dialect #
DBMS-specific SQL variant. ANSI SQL is the baseline, but every vendor has its own extensions (Microsoft T-SQL, Oracle PL/SQL, Postgres PL/pgSQL, etc.). The formatter here covers 13 dialects.
Keyword case #
Capitalization convention for SQL reserved words: classic UPPERCASE (SELECT, WHERE), modern lowercase (select, where), preserve (keep input).
T-SQL #
Transact-SQL, the Microsoft SQL Server and Sybase dialect. Extensions: TOP n, OUTPUT clause, CROSS APPLY, @name variables, GO batch separator, BEGIN TRY/CATCH.
PL/SQL #
Oracle's Procedural Language SQL. Adds to SQL: BEGIN/EXCEPTION/END, explicit cursor, RECORD type, packages, triggers, extended atomic transactions.

Frequently asked questions

Is the formatter compatible with my specific dialect (e.g. CockroachDB, ClickHouse)?
The 13 covered dialects are the most common. CockroachDB is syntactically compatible with PostgreSQL, so use that dialect. ClickHouse has its own specific syntax (FORMAT, custom MATERIALIZED VIEW): use standard SQL for now and tweak by hand if needed. If you need a specific dialect, sql-formatter is open source and new dialects are added regularly.
Are full stored procedures with CREATE PROCEDURE, BEGIN, EXCEPTION supported?
Yes for dialects that have them (T-SQL, PL/SQL, MySQL stored procs). The formatter recognizes BEGIN/END nesting, IF/ELSE, EXCEPTION/WHEN handlers. For multi-statement scripts with DELIMITER (MySQL custom delimiter), the alternate delimiter is recognized.
Can I batch-format thousands of queries?
One at a time from the UI. For batch workflows, equivalent tooling exists as an npm package (sql-formatter) and as a CLI (npx sql-formatter): in 5 lines of Node.js you read a query file and reformat in a loop, integrable into a pre-commit hook or a CI pipeline.
Does it preserve comments (-- and /* */)?
Yes, in format mode. Both inline (--...) and block (/*... */) are preserved and re-indented along with the code. In minify mode they are removed (that is the purpose). To preserve them in minify, the open-source formatter has a denseOperators option but it is not exposed in the current UI.
Does it work offline?
Yes. The parser and rendering load on the first page hit; afterwards the formatter keeps working without a connection, useful in scenarios with intermittent or air-gapped networks.
How are parameterized queries (?, $1, :name) handled?
As opaque tokens: the formatter recognizes them as placeholders and keeps them as-is in the formatted output. Works for ? (mysql/sqlite), $1 (postgres), :name (oracle/mysql), @name (T-SQL).
Can I use the tool to validate SQL syntax?
Indirectly: if the formatter throws a parse error, the query is syntactically invalid in the chosen dialect. But the formatter is not a linter: semantic errors (references to non-existent columns, type mismatches) require the actual DB validating via EXPLAIN or EXECUTE.

Who builds these tools?

Maurizio Fonte, senior IT consultant with 20+ years in PHP, Laravel, unmanaged Linux infrastructure, applied cybersecurity and AI/LLM integration. Production backends, legacy code modernization, security audits, custom AI agents and MCP servers: the work behind every tool published here.

About Maurizio Fonte