Reformatting a query you copied out of a log file, ORM output, or chat message into something diffable and reviewable. Normalising team conventions (UPPERCASE keywords, consistent indentation) before committing a migration script or schema change. Squashing a long pretty-printed query into a single line so it fits in a YAML config file, environment variable, or one-line CLI argument. Spotting structural problems — unbalanced parentheses, missing commas in the SELECT list, or a JOIN with no ON clause — that become obvious once the query is properly indented. Preparing a query for code review by applying a consistent visual standard across your team. Debugging complex nested queries or CTEs by expanding them to see the nesting structure clearly.

Paste or type your SQL into the editor. The formatter accepts any mix of whitespace, line breaks, and casing. Choose your SQL dialect: ANSI (default), MySQL, or PostgreSQL. This affects how keywords and operators are recognised and formatted. Toggle between pretty-print (readable, indented) and minify (single line) modes using the buttons at the top. The formatter tokenises your input, applies indentation rules and clause breaks, and reconstructs the SQL. All processing happens in your browser. Copy the output directly or download it as a file.

The formatter is structural, not semantic. It won't validate whether your SQL is correct or executable — only how to indent the tokens it sees. A syntax error in the input becomes a syntax error in the output. Dialect-specific keywords vary. ILIKE , RETURNING , and LATERAL are PostgreSQL; STRAIGHT_JOIN and SQL_CALC_FOUND_ROWS are MySQL-only. Pick the correct dialect or those words won't be recognised as keywords and may format unexpectedly. String literals are preserved verbatim. Multi-line strings in single quotes keep their line breaks; the formatter doesn't reflow or escape text inside '...' or "..." . Comments get isolated on their own lines. Inline comments (e.g. -- TODO mid-clause) are moved to their own line during pretty-print to avoid breaking clause alignment. Minify strips all comments. If you need to preserve comments, use pretty-print mode instead.

SQL Formatter

Format and beautify SQL with proper indentation, or minify to a single line. Dialect-aware (ANSI / MySQL / Postgres).

Input

Mode

Dialect

Indent

Keyword case

Output

Enter input above to see the result.

What is this for?

SQL ranges from a one-liner you typed in psql to a 200-line analytics query that nobody can read until it's indented properly. This formatter takes any SELECT, INSERT, UPDATE, or DDL statement and rewrites it with consistent indentation, line breaks before each clause, and uniform keyword casing. The minify mode does the opposite — squashes everything to a single line for embedding in code, YAML files, or CLI arguments. The whole thing runs in your browser; queries never leave the page.

When to use it

Reformatting a query you copied out of a log file, ORM output, or chat message into something diffable and reviewable.
Normalising team conventions (UPPERCASE keywords, consistent indentation) before committing a migration script or schema change.
Squashing a long pretty-printed query into a single line so it fits in a YAML config file, environment variable, or one-line CLI argument.
Spotting structural problems — unbalanced parentheses, missing commas in the SELECT list, or a JOIN with no ON clause — that become obvious once the query is properly indented.
Preparing a query for code review by applying a consistent visual standard across your team.
Debugging complex nested queries or CTEs by expanding them to see the nesting structure clearly.

How it works

Paste or type your SQL into the editor. The formatter accepts any mix of whitespace, line breaks, and casing.
Choose your SQL dialect: ANSI (default), MySQL, or PostgreSQL. This affects how keywords and operators are recognised and formatted.
Toggle between pretty-print (readable, indented) and minify (single line) modes using the buttons at the top.
The formatter tokenises your input, applies indentation rules and clause breaks, and reconstructs the SQL. All processing happens in your browser.
Copy the output directly or download it as a file.

Common gotchas

The formatter is structural, not semantic. It won't validate whether your SQL is correct or executable — only how to indent the tokens it sees. A syntax error in the input becomes a syntax error in the output.
Dialect-specific keywords vary. ILIKE, RETURNING, and LATERAL are PostgreSQL; STRAIGHT_JOIN and SQL_CALC_FOUND_ROWS are MySQL-only. Pick the correct dialect or those words won't be recognised as keywords and may format unexpectedly.
String literals are preserved verbatim. Multi-line strings in single quotes keep their line breaks; the formatter doesn't reflow or escape text inside '...' or "...".
Comments get isolated on their own lines. Inline comments (e.g. -- TODO mid-clause) are moved to their own line during pretty-print to avoid breaking clause alignment.
Minify strips all comments. If you need to preserve comments, use pretty-print mode instead.

Limitations and alternatives

This formatter handles indentation and casing well, but it's not a SQL linter or validator. For catching bugs, enforcing style rules, or running static analysis in CI/CD pipelines, use a dedicated tool like sqlfluff or pgFormatter. For dialect-specific features or complex parsing, consult your database engine's documentation.