SQL Formatter

Make a long query readable

Paste your SQL, pick the dialect that matches your database, and the formatted query appears below. Use Sample query to see what the tool does with a typical report query and an update statement.

Choose the options

• Dialect tells the formatter how to read quotes, operators and keywords. If you are unsure, start with Standard SQL, then switch to PostgreSQL, MySQL or SQL Server and compare.
• Keyword case sets select to SELECT (upper), keeps it lowercase, or leaves your text as typed. Upper case for keywords is the most common team convention because it separates commands from table and column names at a glance.
• Indent can be 2 spaces, 4 spaces or a tab. Match your repository's style so diffs stay small.
• Lines between queries adds blank lines between statements separated by semicolons.

Minify for compact strings

Switch to Minify when you need SQL on one line, for example inside a log message, a configuration value or a code string. Minify removes -- line comments and block comments, collapses whitespace, and never alters quoted text. Hints such as /*+ ... */ and MySQL's /*! ... */ are kept, since removing them can change execution. If your strings use backslash escapes, as in MySQL, tick the backslash option.

Fixing errors

The formatter reports the first thing it cannot read. Typical causes:

1. An unclosed single quote or parenthesis.
2. The wrong dialect, such as T-SQL brackets under MySQL.
3. Template placeholders like {{ table }} or $1 mixed into the query.

Good habits

• Format a query before reviewing it. Long joins and nested subqueries become easy to scan.
• Keep one condition per line in WHERE clauses so changes show clearly in a diff.
• Never paste real credentials or customer data into any tool you do not control. This one runs locally, but the habit is worth keeping.