SQL Formatter & Beautifier

How to use this tool

1. Paste a SQL query into the input area, or open a local .sql or text file.
2. Select the SQL dialect that matches your database.
3. Choose indentation and keyword casing; Advanced formatting also controls function and data type case and AND/OR line breaks.
4. The formatted SQL appears instantly in the output panel.
5. Choose Formatted or Minified output, then copy it or download a .sql file.

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 recognize the right syntax and keyword set. It changes formatting rules; it does not translate a query from one database engine to another.

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: choose Minified output to collapse formatter whitespace before logging queries. Quoted values and identifiers remain intact, and line comments keep their line break so they cannot hide the next statement.
• Error messages: database error messages often include the offending SQL in a single line. Paste it here to make the structure readable before debugging.

Open and save SQL files privately

Use Open file to read a local .sql or text file, or drop one onto the input area. The browser reads the file with its local file API, and the bundled formatter processes its text on this device. Large files can take longer because formatting runs in the page, so the tool displays a size note above 2 MB. Use Download to save the current formatted or minified result as a new .sql file. The original file is not overwritten.

This workflow is useful when reviewing a migration, preparing a query for a pull request, or cleaning up a statement copied from a production log. For example, opening a migration and selecting PostgreSQL helps make its clauses and joins easier to scan before review. Formatting does not validate a query against a live database, change its meaning intentionally, or verify that it will run on the selected engine.

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. The statement count shown above the output is a convenience estimate based on semicolons; semicolons inside comments or quoted text can make that count differ from the database's actual statement boundaries.