Loading Techie Utils…

Oracle SQL Formatter

Format Oracle SQL queries with consistent indentation and keyword case. Free, and runs entirely in your browser — nothing you enter is uploaded or stored.

About SQL Formatter

A query that arrives as one long line is not readable, and the queries that most need reading are exactly the ones that arrive that way: pulled out of a log, copied from an ORM's debug output, or pasted from a colleague who wrote it in a single sitting. This puts each clause on its own line and indents the joins and conditions underneath.

SQL is not one language, and the places the dialects differ are the places a careless formatter destroys a query. MySQL quotes an identifier with backticks, SQL Server with brackets, and everything else with double quotes — which in PostgreSQL means an identifier and in MySQL means a string. MySQL also treats # as a comment where other dialects read it as something else, and PostgreSQL has dollar-quoted blocks that wrap whole function bodies containing semicolons and quotes of their own.

So the query is tokenised first, with every string, identifier, comment and dollar-quoted block kept whole, and only then laid out. A token that was never split cannot be mangled, which matters far more than the prettiness of the result. Nothing is executed and nothing is validated — it lays out the text you give it, which is what makes it usable on a query that does not run.

Where it helps

  • Knows which characters quote an identifier in each dialect, so a name with a space or a keyword in it survives formatting.
  • Keeps strings, comments and PostgreSQL dollar-quoted blocks whole, because whitespace inside them is data.
  • Puts each clause on its own line and indents joins and boolean conditions under the clause they belong to.
  • Upper-cases keywords on request, which is the convention nearly every codebase follows.
  • Formats a query that does not parse or does not run, which is when formatting is most needed.
  • Runs in the browser, so a query carrying real table names and filters is not sent anywhere.

Limits

  • It is a formatter, not a parser: it will not tell you a query is invalid, and it cannot reflow something it has misread.
  • Very long expressions and subqueries are indented but not wrapped to a column width.
  • Dialect-specific hints and procedural blocks — PL/pgSQL, T-SQL control flow — are laid out by the same clause rules and may not match house style.
  • Nothing is executed and no schema is consulted, so it cannot say whether the query is correct, only how it reads.

Frequently asked questions

Does the dialect really matter?

For the layout, rarely. For not breaking the query, yes: the three families quote identifiers differently, and a formatter that reads a MySQL backtick as an ordinary character will split a table name with a space in it into two tokens. Choosing the dialect is how you avoid that.

Will it change what my query does?

It should not — only whitespace between tokens changes, and everything quoted is preserved exactly. The one thing worth checking is a query that was already invalid, where a formatter has no correct answer to give.

Can it format a whole migration file?

Several statements separated by semicolons are handled, each starting a fresh block. PostgreSQL function bodies in dollar quotes are kept intact rather than reformatted, since their contents are a different language.

Related tools

More Web Development tools