SQL Formatter

Enter input above to see the result.

Readable SQL in one paste

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.

From log dump to reviewable query

• 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.

Dialect, indent, and keyword casing

• 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.

Structural formatting, not semantic validation

• The formatter won't catch SQL bugs. 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.

When to reach for a linter instead

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.

A missing ON clause, exposed by indentation

Paste a query pulled from a log as one long line. Pretty-print puts each clause on its own line with uppercase keywords — and a JOIN that's missing its ON clause, or a SELECT list missing a comma, becomes obvious the instant the structure is laid out. Minify mode does the reverse for embedding in YAML or a CLI argument.

Dialects, validation, minify safety, and lowercase keywords

Which SQL dialect does it support? Standard SELECT/INSERT/UPDATE/DDL across the common dialects. It formats syntax; it doesn't enforce one vendor's exact grammar.

Does it validate or run the query? No — it's a formatter, not a linter or an engine. It rearranges text and never connects to a database, so queries never leave the page.

Is minify safe? Yes for embedding — it collapses whitespace without changing tokens, and string literals and comments are preserved.

Can I keep lowercase keywords? Keyword casing is a setting. Uppercase is the default for readability, but match your team's house convention.

Tokenise, re-lay, ship — what the formatter actually does

A SQL formatter tokenises the statement — keywords, identifiers, literals, operators — then re-lays it out against consistent rules: keywords aligned, each column on its own line, JOINs and their ON conditions indented under the tables they attach to. It only touches whitespace and case, never the logic, so the query runs identically before and after. The value is diff-ability and review: a consistently formatted query makes an accidental cross join, a missing join condition, or a mis-scoped WHERE visible at a glance, where a one-line wall of SQL hides all three.

The implicit-join trap

Letting each developer format by hand, so every edit produces noisy version-control diffs where real logic changes drown in reflowed whitespace. Agree one style and apply it automatically. The readability trap the formatter exposes is the implicit join — comma-separated tables in the FROM clause with the join condition buried in WHERE — which is far easier to get wrong than an explicit JOIN … ON, and far easier to spot once the query is laid out.

Related

Tidy API payloads with the JSON formatter, move query results to a spreadsheet with the CSV to JSON converter, and reformat config with the YAML ↔ JSON tool. Keeping a team consistent: SQL formatting standards for teams.