dialect-aware · no execution

SQL formatter

Re-indent a query with the dialect’s own token rules, so strings and comments survive the trip.

0 characters

Formatting runs in this tab. Queries often name internal tables and literal values, so nothing is uploaded.

Short answer: paste the query, pick the dialect, read the result. The summary reports statements and lines; nothing is executed and nothing is validated.

What “formatted” means here

Keywords are cased as you asked, clauses break onto their own lines, and continuation lines are indented by the width you chose. Strings, comments and quoted identifiers are carried through unchanged, which is the whole reason this usessql-formatter rather than a chain of regular expressions.

What it will not tell you

Reviewing a migration? Paste both versions into the text diff after formatting, so the diff shows semantic changes rather than indentation noise.

SQL formatting questions

Does formatting also validate the query?

No. A formatter tokenises; it does not parse the grammar or check that a table exists. `SELECT FROM WHERE` still formats, and that is deliberate — claiming a green tick for validity would be a lie. Run the query against the database, or use EXPLAIN, for that.

How are strings and comments treated?

They are preserved byte for byte, including dollar-quoted blocks in PostgreSQL and backtick identifiers in MySQL. That is why a real tokenizer matters: a regex that re-indents on keyword boundaries will happily rewrite the inside of a string literal.

Why does the dialect matter?

Because the token rules differ. MySQL escapes identifiers with backticks, PostgreSQL supports dollar-quoted strings and :: casts, T-SQL uses [brackets], and BigQuery has backticked project.dataset.table names. Choosing the wrong dialect changes what counts as an identifier.

Is the SQL uploaded?

No. Formatting happens on the string in this tab. Queries often carry table names, column names and literal values, so nothing is sent anywhere and nothing is stored.

Related tools