SQL Formatter

Format a query in the dialect you actually run, choosing keyword casing and indentation.

Runs on your deviceDeveloperWorkingNo account needed

What this tool does

SQL Formatter puts your query through a real parser for the dialect you pick, then prints it back with one clause to a line and every keyword cased the way you asked. The layout is rebuilt rather than patched, so a statement pulled out of a log, unwrapped from a string in application code, or emitted by an ORM as one enormous line all come out in the same shape as everything else you format here.

Keyword casing is the setting most people arrive for, and it is worth knowing what it touches. UPPERCASE, lowercase or Leave as typed applies to the words the chosen dialect recognises as keywords; table names, column aliases and the insides of string literals keep the case you typed. So, less obviously, do function names and data types: sum, count, int and varchar are never touched by this setting, which is why the sample query comes back with SELECT, FROM and GROUP BY shouted around a lowercase sum(). The edge case in the other direction is a column named after a keyword, which gets recased along with the rest — select year, name, value comes back with YEAR and VALUE shouted while name is left alone — so quote those identifiers, or set keywords to Leave as typed, if that bothers you.

What it will not do is tell you whether the query is correct. This is a formatter, not a linter and not a database connection: there is no schema, nothing is executed, and select * form t is laid out without a word of complaint because form parses perfectly well as an alias. It stops only when the text will not parse at all, and what you get then is the parser library's own complaint, passed through unedited. An unclosed quote, or a placeholder the chosen dialect has never heard of, comes back as one readable line naming the position it gave up at. An unclosed bracket is the ugly case: the library answers with tens of thousands of characters of its internal grammar rules, and the line and column you actually wanted sit at the very front of that wall of text. All of this happens inside this browser tab, so the query, its table names and any values sitting in the WHERE clause are never uploaded; only the formatting library itself is fetched from this site the first time you run the tool.

How to use it

  1. Paste the query. Drop it into the input box, or press Load sample for a joined and grouped query that shows the shape of the output. Several statements separated by semicolons can go in together.
  2. Choose the dialect. Sixteen are offered, from Standard SQL through PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, BigQuery, Snowflake, Redshift, Spark, Hive, Db2, Trino, N1QL and TiDB. The choice decides which words count as keywords and which placeholder and quoting styles will parse.
  3. Set the casing and the indentation. Keywords uppercase, lowercase or left exactly as typed; two spaces, four spaces or a tab for each level of nesting.
  4. Space the statements out, then copy. Blank lines between statements can be set anywhere from none to five. The summary under the output counts the statements it formatted and names the dialect it used.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Reading a query out of a slow-query log

Logged SQL arrives as a single flattened line. Indenting it is the quickest way to see which join or correlated subquery is doing the damage.

Reviewing SQL that a query builder wrote

An ORM emits output that is correct and close to unreadable. One pass gives it the same shape as hand-written SQL, which is what makes a code review of it possible.

Putting a repository's queries into one style

Migrations and reports written by different people drift into different casing and indentation. Formatting each with the same settings means diffs show real changes rather than whitespace.

Pasting a query into a ticket or a document

Two-space indentation and uppercase keywords survive a paste into an issue tracker far better than a wall of unbroken text does.

Questions

Is my SQL sent anywhere?
No. The parser is JavaScript running in this tab, so the query stays on the machine you typed it on. That matters more for SQL than for most text, because a WHERE clause routinely carries customer email addresses, account numbers and internal identifiers alongside your schema.
Why does it reject a query that runs fine on my database?
Almost always the dialect. Standard SQL does not know a :name placeholder and refuses it, while PostgreSQL formats the same query without complaint; backticks, bracket identifiers and dialect-specific functions behave the same way. Pick the dialect you actually run and the parse error usually goes away.
Will it tell me my query is wrong?
Only when it cannot parse it. A mistake that still tokenises — form where you meant FROM, a column that does not exist, a join on the wrong key — is formatted and handed straight back, because there is no schema here and nothing is run. Use it for layout, not for correctness.
Does it change my query?
Only its whitespace and its keyword casing. Identifiers, string literals, numbers and comments come through as written, and both -- line comments and /* block */ comments stay where they sit. Blank lines you had inside a statement are not preserved, because the layout is rebuilt from the parse rather than edited in place.
Why is one of my keywords still lowercase?
Because the dialect you picked does not treat it as a keyword. Format a query ending in limit 5 as SQL Server (T-SQL) and it stays lowercase, since T-SQL has no LIMIT — the casing rule only reaches words that dialect recognises.
How large a query can I paste?
Everything is held in the tab's memory, so ordinary queries and long migration files are comfortable, and a very large dump will make the browser sluggish before any limit is reached. Cutting it down to the statements you care about is quicker than waiting.
Can it turn the statements into rows I can open in a spreadsheet?
Not here — that is SQL to CSV, which reads INSERT … VALUES statements and writes their values out as a table. This tool changes how the SQL is laid out and nothing else.

Related tools