Paste a one-line SQL query from a log or an ORM and get it back readable: one clause per line, columns indented, keywords in capitals.
Formatting...
Type or paste in the first box and the second updates as you go. Pick the Dialect your database speaks, choose a 2 or 4 space indent, and turn UPPERCASE off to leave keywords as you typed them. Press Minify to go the other way and squash the query onto as few lines as it will go. Everything runs in your browser and nothing is uploaded.
What it changes and what it leaves alone
| It changes | It never changes |
|---|---|
| Line breaks: one clause per line | Text inside 'strings' |
| Indentation, 2 or 4 spaces | Quoted identifiers: "Name", `name`, [Name] |
| Keyword, function and type case, when UPPERCASE is on | Comments, -- line and /* block */ |
| Spacing around commas and operators | Table and column names, and their case |
| Blank lines between statements | What the query does |
Upper-casing only touches words the dialect treats as keywords, functions or
types. A column called name stays name, and so does 'select' in a string.
The catch is a column named after a reserved word, such as date, value or
user: the dialect reads it as a keyword, so it comes out as DATE. The query
still works, since unquoted names are not case sensitive in most databases, but
quoting a name like that in your dialect's quotes avoids both the confusion and
the clash.
Pick the right dialect
Most SQL is the same everywhere, but each database adds its own syntax. With the wrong dialect picked the formatter may not recognise part of the query, and says so.
| Dialect | Pick it when you see |
|---|---|
| Standard SQL | Plain SELECT, JOIN, GROUP BY and nothing vendor specific |
| PostgreSQL | ::int casts, $1 parameters, $$ quoted function bodies, ILIKE, RETURNING |
| MySQL | `backtick` identifiers, # comments, LIMIT 10, 20 |
| SQL Server (T-SQL) | [bracket] identifiers, @variables, TOP 10, GO |
| SQLite | AUTOINCREMENT, PRAGMA, and backticks or brackets for names |
Format or minify
| Format | Minify | |
|---|---|---|
| Line breaks | One clause per line | Only after a -- comment |
| Reads well | Yes | No |
| Use it for | Reading, code review, pasting into a pull request | A query in a string, a config value or a one-line log |
Minify keeps a line break after each -- comment, because that comment runs to
the end of its line. Joining the next line onto it would turn the rest of the
query into part of the comment.
When the SQL will not parse
The formatter reads each dialect's grammar, so it notices when something does not fit. Rather than refusing, it formats the statements it understands properly, lays out the rest with simpler rules (a new line before each clause, keywords re-cased, strings and comments untouched) and shows a note with roughly where it stopped. The usual causes:
- The wrong dialect.
[Order Details]is a name in T-SQL and a syntax error in Standard SQL. - A half-finished query. An unclosed bracket or a missing value after
=. - Template placeholders.
{{ table }}or${id}from a templating language is not SQL. Swap in a real name to format it. - A typo.
SELCTor a stray comma beforeFROM.
Common SQL style rules
There is no single standard, but most style guides agree on these. The Format button takes care of the layout; the naming and the semicolons are up to you.
- Keywords in capitals, names in lowercase
snake_case. The Case Converter turnsfirstNameintofirst_name. - One clause per line, with its contents indented below it.
- One column per line in a long
SELECT, so a diff shows the one that changed. ANDandORat the start of a line, so a condition can be commented out without breaking the one above it.- A semicolon at the end of every statement, even where the database allows you to leave it off.
How it works
- Every block comment is set aside, so its inner lines keep their exact spacing.
- The query is parsed with sql-formatter, an open source formatter with a grammar for each dialect, and printed with your indent and keyword case.
- If that fails, the input is split into statements at each
;that is not inside a string or a comment, and each statement is tried on its own. The ones that still fail get the simpler layout. - The comments are put back, and for Minify the whitespace between the pieces is collapsed.
The work happens in a Web Worker, a background thread in your browser, so formatting a large script never freezes the page.
Related
- The SQL cheat sheet for the syntax of
SELECT, joins,GROUP BY, window functions and the rest. - JSON Formatter and Validator, for the JSON a query returns or stores in a column.
- Case Converter, for turning names into
snake_caseorcamelCase. - Hash Generator, for checking the checksum of a database dump.
Common questions
What does a SQL formatter do?
A SQL formatter, also called a SQL beautifier or pretty printer, re-lays out a query so it is easy to read: each clause such as SELECT, FROM and WHERE starts its own line, the columns and conditions under it are indented, and keywords are upper-cased. It only changes whitespace and letter case. The query does exactly the same thing afterwards.
How do I format SQL online without uploading it?
Paste it into the box at the top of this page. The formatting runs in your browser, in a background thread, and the query is never sent to a server. The site records that the tool was used, with the settings chosen and the length of the input, but never the SQL itself.
Is this a T-SQL formatter for SQL Server?
Yes. Pick SQL Server (T-SQL) in the Dialect list and it understands square-bracket identifiers such as [Order Details], variables such as @id, TOP, and the other T-SQL syntax. The same list has PostgreSQL, MySQL and SQLite. Standard SQL is the default and handles most everyday queries.
Why does it say my SQL could not be fully parsed?
The formatter understands each dialect's grammar, and something in the query did not fit it. The usual causes are the wrong dialect (square brackets in Standard SQL, backticks outside MySQL and SQLite), a half-finished query, a typo, or a vendor extension it does not know. It still formats the query with simpler rules and says roughly where it stopped, so check that spot or pick a different dialect.
Does formatting change my strings or comments?
No. Text inside quotes, quoted identifiers and comments is kept exactly as you wrote it, including the spacing and case inside it. Only the whitespace between the parts of the query changes, and the letter case of keywords when UPPERCASE is on.
Should SQL keywords be uppercase?
Databases do not care: SELECT, select and Select all mean the same. Uppercase keywords are a convention that makes the structure of a query stand out from the table and column names, and most style guides use it. Some teams prefer everything lowercase. Pick one and match the code around you.
How large a query can it handle?
Large ones. A 1 MB script takes a few seconds, and it runs in the background so the page keeps responding while it works. Past a few megabytes, a command-line formatter such as the sql-formatter CLI or pgFormatter is the better fit.