Which SQL dialects are supported?

This tool supports Standard SQL, PostgreSQL, MySQL, MariaDB, T-SQL (SQL Server), SQLite, and PL/SQL (Oracle). Select the appropriate dialect to get dialect-specific keyword handling.

Does my SQL leave my browser?

No. All formatting runs entirely in your browser using the open-source sql-formatter library. Nothing is sent to any server.

Can I format multiple SQL statements at once?

Yes. Paste multiple statements separated by semicolons and the formatter will handle each one. The status bar shows a statement count.

What does "keyword case" control?

SQL keywords like SELECT, FROM, WHERE, and JOIN are case-insensitive in most databases, but convention matters for readability. Choose UPPERCASE (most common), lowercase, or Preserve (keep as-is) to match your team's style guide.

SQL Formatter & Beautifier

What is SQL formatting?

SQL (Structured Query Language) is the standard language for querying and manipulating relational databases. Raw SQL, especially queries generated by ORMs, query builders, or copy-pasted from logs, is often a single dense line with no whitespace. Formatting adds consistent indentation and line breaks so the logical structure is immediately readable.

Why use a SQL formatter?

Formatted SQL is easier to review in pull requests, debug in production logs, and explain to teammates. Consistent keyword casing and indentation also helps editors and IDEs apply correct syntax highlighting. Most style guides mandate UPPERCASE keywords. This tool can enforce that automatically.

Dialect differences

SQL dialects differ in quoting conventions, proprietary keywords, and function names. PostgreSQL uses double quotes for identifiers and $1 for parameters. MySQL uses backtick quoting. T-SQL uses bracket notation and TOP instead of LIMIT. Selecting the correct dialect lets the formatter handle these differences accurately.

Keyword case conventions

SQL keywords are case-insensitive in every major database, but most style guides recommend one convention for consistency. UPPERCASE keywords are the traditional standard and remain the most common. Some teams prefer lowercase for a cleaner visual separation from identifiers. Choose whichever matches your project's style guide.

Formatting for specific contexts

Pull request diffs: format SQL before committing. When formatted SQL is checked in consistently, git diffs show only meaningful changes rather than formatting noise. Running the formatter as a pre-commit hook ensures this automatically.
Log output: strip extra whitespace (use compact/minified mode) before logging queries to avoid multi-line log entries that break log parsers and Elasticsearch ingestion.
Error messages: database error messages often include the offending SQL in a single line. Paste it here to make the structure readable before debugging.

Idempotency

A well-implemented SQL formatter is idempotent: formatting already-formatted SQL produces no changes. This property is important for pre-commit hooks - running the formatter on a file that hasn't changed should produce a clean diff and exit without modifying the file. If your formatter is not idempotent, it will cause unnecessary churn in version control.