Skip to content
Burrows Tools

SQL Formatter

Paste a query and get it back the way you would have written it with more time: one clause per line, list items and boolean conditions on their own lines, subqueries and column definitions indented, keywords in the case you prefer. The same page minifies, collapsing a statement to a single line for a config file or a bug report — comments are removed rather than left behind to swallow everything after them. Pick your dialect and the parser follows its rules: MySQL backticks and hash comments, PostgreSQL dollar quoting and double-colon casts, SQL Server brackets and GO batches, SQLite's mixture of all three. Nothing is uploaded, which matters more here than on most pages: a query names your real tables and usually carries real values in its WHERE clause. Formatting happens in this tab, with no signup and no server round trip, and the result is stable — running it twice gives you the same text.

Parsed in your browser — nothing is uploaded. Up to 100,000 characters.

ANSI rules: "quoted identifiers", '' escapes, -- and /* */ comments.

Paste SQL and choose Format or Minify.

How to use the sql formatter

  1. Paste your SQL into the input box, or press Load example to see the layout first.
  2. Choose the dialect you are writing for so quoting, comments, and string escapes are read correctly.
  3. Pick whether keywords come out uppercase, lowercase, or exactly as you typed them, and how far each level is indented.
  4. Press Format for readable output or Minify to strip it to one line, then copy the result.

Frequently asked questions

Is my SQL uploaded anywhere?
No. The parser and the formatter are JavaScript running in your browser, so the query never leaves the tab — no request is made when you press Format. That is the difference that matters for SQL, because a real query names real tables and often has real identifiers, keys, or personal data sitting in its WHERE clause.
Which SQL dialects are supported?
Standard (ANSI) SQL, MySQL and MariaDB, PostgreSQL, SQL Server (T-SQL), and SQLite. The dialect changes how the text is read, not what is allowed: backtick and bracket identifiers, MySQL hash comments and backslash escapes, PostgreSQL dollar-quoted bodies, E'' strings and $1 parameters, T-SQL N'' literals, @variables and GO batch separators, and nested block comments where the dialect nests them.
Can formatting change what my query does?
It only rewrites whitespace and the case of recognised keywords. Every other character comes through byte for byte, including the contents of strings, quoted identifiers, and comments, so the statement you get back runs exactly as the one you pasted did. Minifying is the one place something is dropped: comments have to go, because collapsing to one line would leave a line comment hiding the rest of the statement.
Why is a word I use as a column name in capitals?
It is on the keyword list, and unquoted identifiers are case-insensitive in every dialect here, so the change is cosmetic rather than a rename. The list is deliberately conservative for that reason: words that are as often column names as keywords — text, date, status, value, count — are left exactly as you typed them. Choosing 'Leave as typed' turns recasing off completely, and quoted identifiers are never touched.
Is there a limit on how much SQL I can format?
100,000 characters, roughly 100 KB, per run. The limit is there because everything happens on the page's own thread: work is bounded so that a pathological input — thousands of nested subqueries, say — cannot freeze the tab. Indentation stops moving right after 24 levels for the same reason, though the structure below that is still laid out correctly.

Related tools