Orpheus

Format SQL

A readable shape for a query you inherited.

Options
Keywords
One column per line
Result

Everything is processed in this tab. Nothing you paste is sent anywhere.

Every tool runs entirely in your browser. Your files are never uploaded to a server.

Formatting SQL puts each major clause on its own line and cases keywords consistently. It changes only the layout — the query executes identically, since SQL ignores whitespace outside string literals.

How to use SQL Formatter

  1. Paste your query. However it arrived — one line is the usual case.
  2. Choose keyword casing. Uppercase keywords are the long-standing convention.
  3. Copy the formatted query. Behaviour is unchanged; only whitespace and casing move.

About formatting SQL

SQL treats whitespace as insignificant outside string literals, which means formatting is purely a readability exercise and carries no risk to behaviour. That is worth stating because a query is often the artefact people are most reluctant to touch — it works, it is going to production, and reformatting feels like a change. It is not one; the parser sees the same token sequence either way. The conventional layout puts each major clause on its own line, because those clauses are what the reader is looking for. Finding the FROM in a two-hundred-character single line means reading the whole thing; finding it at the start of a line takes no effort at all. Joins get the same treatment, with their ON conditions indented beneath, which makes the shape of a multi-table query visible before any of it is read closely. Keyword casing is convention rather than requirement — SQL keywords are case-insensitive — and uppercase is the long-standing choice because it visually separates the language from the identifiers around it. The one place a formatter can genuinely break something is string literals. A keyword inside a quoted value is data, and uppercasing it or collapsing whitespace within it changes what the query does. Extracting quoted sections before any other transformation and restoring them afterwards is the only reliable way to avoid it, and it is the difference between a formatter that is safe on real queries and one that works on the examples in its own documentation.

Frequently asked questions

Does formatting change how the query runs?
No. SQL ignores whitespace outside string literals, so layout has no effect on parsing, planning or results. The only thing that could change behaviour is altering a string, which is why literals are extracted before anything else happens.
Why uppercase keywords?
Convention, and a useful one. SQL keywords are not case sensitive, but uppercasing them separates the language from the table and column names around it, which makes an unfamiliar query far quicker to scan. Some teams prefer lowercase throughout for the same consistency reason.
Will it handle a keyword inside a string?
Yes. Anything inside single quotes, double quotes or backticks is lifted out before the keyword pass and restored afterwards, so a column value containing the word "order" is not treated as a clause.
Does this validate my SQL?
No. It is a formatter, not a parser — an invalid query will be laid out neatly and remain invalid. Validation is dialect-specific, and there are enough differences between Postgres, MySQL, SQLite and SQL Server that a general checker would be misleading.
Is my query uploaded?
No. Formatting runs in your browser, which matters because queries routinely contain table names, business logic and occasionally real values that should not be pasted into an unknown service.

Last updated