SQL Formatter

Type or paste SQL in the left box, or press Open .sql file, and the formatted version appears on the right straight away. There is no Format button to press: the output follows every change you make, and a small counter shows how many lines and statements it holds. Copy puts the result on your clipboard, and Download .sql saves it as a file.

The page is built around one rule: it may move spaces and line breaks, and it may change the letter case of SQL keywords if you ask, but it never touches what the query means. Text in quotes, quoted table and column names, numbers and comments come out exactly as they went in.

Pick your dialect from the list first. MySQL, PostgreSQL, SQL Server, Oracle, SQLite and BigQuery each quote names and write comments a little differently, and the tool needs to know which rules apply so it can tell a string from a name and a comment from an operator.

Each main clause, SELECT, FROM and WHERE, starts at the left edge, and the items under it are indented one step. The select list puts one column per line, with the comma at the end of the line.

The CASE expression gets its own block: each WHEN and the ELSE sit one step deeper, and END lines up with CASE. The JOIN starts a new line and its ON condition goes on the next line, indented, so long join conditions are easy to scan.

The subquery inside IN ( ) is laid out as a query of its own, one level deeper, and the closing bracket returns to the level of the condition it belongs to. The AND after it starts its own line. Short clauses such as LIMIT 10 stay on one line, because there is nothing to list.

Notice what did not change: 'big', 'small', the table aliases and the column names. Only keywords were capitalised and only whitespace moved.

A query copied from an application log usually arrives as one long line. A sql formatter online is the fastest way to turn it into something you can read: paste, look at the right-hand box, and the structure is visible. Because everything happens in the page, the result updates while you type, even on long scripts.

The output box is read-only, so you cannot change the result by accident. To try a different layout, change a setting rather than editing the output; the input stays exactly as you left it. Clear empties the input box when you want to start over.

Several statements can go in at once. Each semicolon ends a statement, the counter above the output tells you how many it found, and the Empty lines between statements setting decides whether they are separated by 0, 1 or 2 blank lines.

You get a sql formatter free of accounts, quotas and upgrade screens: paste as much SQL as you like, as often as you like. There is no paid version with extra options, so every setting described on this page is available to everyone.

Because the formatting runs in your browser, there is no server cost per query, and so no reason to limit how many queries you format or how long they are. Very large scripts depend only on the speed of your device; a typical query is formatted before you finish typing.

The output is plain SQL text with nothing added: no header, no watermark, no tracking comment. What you copy is ready to paste into your editor, a migration file, a pull request or a ticket.

A sql formatter and beautifier should make a query easier to read without any risk of making it do something different. This one works in two stages. First a tokenizer reads your SQL piece by piece and labels every part: word, text in quotes, quoted name, number, comment, operator, bracket, comma or semicolon. Then the layout step joins those pieces again with new spaces and line breaks.

The pieces themselves are never edited. A string such as 'it''s here' keeps its doubled quote, a name such as "Order Date" keeps its space and capitals, 1.50e3 stays 1.50e3, and a comment keeps every character. Placeholders such as ?, :name, @name and $1 are kept as they are too.

The only things that change are whitespace and, if you choose, the case of SQL keywords. With Keyword case set to UPPER, words such as select, from, left join and group by become SELECT, FROM, LEFT JOIN and GROUP BY, and common function names written before a bracket, such as count( or coalesce(, become COUNT( and COALESCE(. With lower, keywords become lowercase and function names stay as typed. A word right after a dot, as in t.order, is treated as a column name and left alone. Keep as typed leaves every word exactly as you wrote it.

What it does not do is rewrite the query. It does not add or remove brackets, reorder columns, expand SELECT *, add aliases or change join syntax. That is deliberate: the formatted SQL should return exactly what the original returned.

Indent: two spaces is compact and common in application code, four spaces matches many style guides, and Tab lets each editor show the indent at its own width. The choice only affects the start of lines; spaces inside a line are always single.

Commas: At line end is the familiar style. At line start puts the comma at the front of the next line, as in , u.name, which makes it easy to comment out or add the last column without touching the line above. It applies to SELECT lists, GROUP BY, ORDER BY, SET, RETURNING, PARTITION BY and WITH lists. Rows after VALUES always go one per line with the comma at the end.

AND / OR on their own lines: when it is on, each AND or OR in a WHERE, HAVING or join condition starts a new line one step in. The AND inside BETWEEN … AND … stays on the same line, and conditions inside a CASE expression are not split. Conditions inside ordinary brackets, such as (a = 1 OR b = 2), also stay together, which keeps the grouping visible. Turn the option off to keep short conditions on one line.

Keep comments: on by default. Line comments (-- and, in MySQL, #) end their line, so a new line starts after them; block comments /* */ stay inline where you wrote them. Turn the option off to strip all comments, for example before pasting SQL into a ticket.

The dialect setting changes how the tokenizer reads your text, not how the layout looks. It decides which characters start a quoted name, which start a string, and whether # begins a comment. If the dialect is wrong, the most common symptom is a red error about a quote that is never closed, or a quoted name that gets split into pieces.

When you are not sure, choose the database the query runs on. Standard SQL suits portable queries and most textbook examples. The sections below cover the details for each database.

Choose MySQL / MariaDB in the Dialect list and the tokenizer follows MySQL's rules. Backticks quote names, so `order`, `group` or `user name` are kept exactly, even when the name is also a keyword. Both single and double quotes start strings, as MySQL treats them by default, and a backslash inside a string escapes the next character, so 'it\'s' does not end early.

A # starts a line comment, alongside -- and /* */. In other dialects # is just an operator, which is why the right dialect matters for MySQL scripts exported from tools that write # comments.

MySQL-specific clauses get a sensible layout too: ON DUPLICATE KEY UPDATE starts its own line with each assignment below it, and LIMIT with an offset, such as LIMIT 20, 10, stays together. A sql formatter for mysql that knows these rules can tidy dump files, saved queries and slow-query log entries without breaking a single string.

Pick PostgreSQL and the formatter understands the parts of Postgres syntax that trip up simpler tools. Dollar-quoted blocks, $$ … $$ or $body$ … $body$, are read as one string, so a function body written inside them is kept exactly, line breaks and all. Casts written with :: stay tight to the value, so price::numeric and created_at::date are not split apart.

Double quotes mark names, as Postgres expects, so "userId" keeps its capital letter. E'…' strings allow backslash escapes, and positional parameters such as $1 and $2 are kept as written. JSON operators like ->, ->>, #> and @> are recognised as single operators and get a space on each side.

RETURNING, ON CONFLICT, WINDOW and FILTER (WHERE …) are known, and a sql formatter for postgresql that keeps WITH queries readable is useful for long reports: each CTE name and its bracketed query are laid out as their own block, with the final SELECT back at the left edge.

Choose SQL Server (T-SQL) and square brackets become quoted names, so [Order Details], [dbo].[Customers] and other names with spaces are kept whole. N'…' Unicode strings and @variables are kept exactly as written.

Keywords such as TOP, MERGE and WHEN MATCHED are known, and CROSS APPLY and OUTER APPLY are laid out like joins, each on its own line with the same indent as JOIN.

A sql formatter for sql server is handy for queries copied from execution plans, traces or application logs, where the text often arrives on one line with brackets around every name. Stored procedure bodies are kept token for token, though their layout stays simple: the formatter focuses on queries rather than control-of-flow statements like IF and WHILE.

Oracle SQL follows the standard quoting rules: single quotes for text, with two single quotes for a quote inside it, and double quotes for case-sensitive names such as "OrderTotal". Choosing Oracle (PL/SQL) keeps those rules, and bind variables such as :customer_id are kept exactly as written.

FETCH FIRST 10 ROWS ONLY starts its own line, like LIMIT does in other databases, and NVL(, TO_CHAR( and TO_DATE( are capitalised as functions when Keyword case is UPPER.

Two honest limits: Oracle's alternative quoting, q'[ … ]', is not recognised, so write such strings with doubled quotes before formatting. And PL/SQL blocks (DECLARE, BEGIN, END) are kept token for token but not given a full block layout. As a sql formatter oracle teams can use for everyday SELECT, INSERT, UPDATE, MERGE and DELETE statements, it does the job well.

SQLite accepts three ways of quoting names: double quotes, backticks and square brackets. Choose SQLite and all three are recognised, which matters for schemas created by different tools over the years. PRAGMA, VACUUM and other SQLite words are known keywords and follow your Keyword case setting.

BigQuery uses backticks around full table paths such as `my-project.sales.orders`, and the hyphen inside them is safe because the whole path is one quoted name. Strings accept backslash escapes, and QUALIFY, WINDOW, STRUCT and ARRAY are known. QUALIFY starts its own line, so filters on window functions are easy to find.

Sometimes you need the opposite of pretty: a query that fits on one line inside a string in your code, a config value, a shell command or a CSV cell. Switch Mode to Minify (one line) and you get a sql formatter in single line form: every line break and repeated space is removed, and a space is kept only where two words would otherwise run together.

The result is as short as it can safely be. A space stays between two words, between a number and a keyword, and before a quoted string, but not around commas, brackets or operators. The formatted example above, minified, reads:

As a sql minifier online, the Minify mode has one extra choice: Keep comments. When it is off, every comment is removed. When it is on, comments are kept, and line comments are rewritten as block comments, so -- active only becomes /*active only */. That matters because a -- comment on a single line would swallow everything after it.

The minifier is also careful in two quiet places. A minus followed by a negative number, as in a - -1, keeps its space so it does not turn into the start of a -- comment, and a / followed by * keeps its space for the same reason. Strings, quoted names and numbers are copied exactly, just like in format mode.

Minify is useful for logging, for storing queries in one-line config values and for comparing two queries without whitespace getting in the way. To compare formatted versions line by line, the Diff Checker works better.

Every time the text changes, the tokenizer reads it from start to end, and that reading doubles as a quick check. If something is never closed, the output box is replaced by a red message that names the line and the column where the problem starts, for example Line 4, column 12: This text in quotes is never closed.

That is the full list. This sql formatter and validator does not connect to a database, so it cannot know whether a table or column exists, whether you have permission or whether types match. It also does not check the full SQL grammar: a misspelled keyword, a missing comma between columns or a WHERE before FROM will be formatted, not reported. Run the query against a test database, or use EXPLAIN, to catch those.

Even so, the checks catch the most common copy-and-paste mistakes, a quote lost when a query was cut from a log or a bracket missing at the end of a long subquery, and they tell you exactly where to look.

This formatter is code that runs inside this page. Your queries are not uploaded, not logged and not sent to any database, and they are never executed. The page has no database connection at all, so nothing can read, change or delete your data.

Only your settings, such as the dialect, keyword case, indent and comma style, are stored in this browser's local storage. The SQL itself is not saved. That matters with real data: queries often contain customer names, emails or IDs in their WHERE clauses, and a page that never uploads is a safe place to format them.

Working with API responses next to your queries? The JSON Formatter makes JSON readable and checks it, and CSV to JSON turns exported query results into JSON for an API or a test fixture. The Regex Tester helps when you build LIKE patterns or REGEXP filters and want to try the pattern first.

To review a change to a long query, format both versions with the same settings and paste them into the Diff Checker. With the whitespace made consistent, only the real changes show up.