SQL Formatter

Pretty-print SQL queries with dialect-aware formatting.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Re-lays out a cramped one-line SQL query into indented, keyword-aligned form, using the parsing rules of whichever dialect you choose — Standard SQL, MySQL, PostgreSQL, SQLite, SQL Server T-SQL or BigQuery.

How to use it

1Paste the query — typically one long line pulled from a log, an ORM or a config file.
2Set the dialect, the keyword case (UPPERCASE, lowercase or unchanged) and an indent of 2 or 4 spaces.
3Press Format, then copy the formatted query.

Example

Input: select id,name from users where active=1
Output: SELECT id, name FROM users WHERE active = 1

Dialect is not cosmetic. Standard SQL rejects dialect-specific syntax — a Postgres cast such as a::text, or a T-SQL [bracketed] identifier, fails with "Parse error: Unexpected …" until you select the matching dialect.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. Queries carry table names, schema shape and sometimes literal production values, and none of that is sent anywhere.

Last updated August 2026

Format and beautify SQL queries into readable, consistently-indented statements. Long queries copied from code or logs are often a single unreadable line; formatting them reveals the structure — joins, conditions, and subqueries — so you can review and debug faster.

Paste a query and get clean, standardised SQL back.

Two jobs bring people to a formatter and only one ends at a text box. A single unreadable query — from a log line, an ORM's debug output or someone else's stored procedure — is a paste-once task. One house style across every query in a repository, enforced when a colleague forgets, is not: that wants a formatter in your editor or a pre-commit hook reading a config file, because a dropdown set in a browser tab is not a rule anyone else follows.

Set the dialect before anything else. It is the one control that decides whether the query parses at all — backticks are MySQL, square brackets are SQL Server, and either one under Standard SQL returns a parse error rather than formatted SQL, which reads as a complaint about your query when it is really about the dropdown.

Nothing here checks that your SQL is correct: a stray comma before FROM comes back as neatly indented as a working query.

How it works

Toolvore formats SQL in your browser. Your queries — which may reference internal schema — never leave your device. The formatter is not fetched with the page — it is several hundred kilobytes of grammar, so it downloads the first time you press Format. What comes back is regenerated rather than patched: the query is parsed into tokens and the whitespace written fresh, so blank lines left between clauses and any alignment done by hand are gone. Comments survive, though a block comment sitting mid-line is pushed onto a line of its own, and several statements separated by semicolons are each formatted and spaced apart. Keyword case reaches reserved words only — identifiers, function names, data types and anything inside quotes keep the case you typed, which is why a column called order comes back shouting. Function names it does not recognise gain a space before the bracket, so my_udf (a) sits beside an untouched coalesce(b, c).

Common use cases

Making long or minified queries readable for review
Standardising SQL style before committing
Debugging complex joins and nested subqueries
Cleaning up queries pulled from application logs
Making a generated query from a BI or reporting tool readable enough to check
Reindenting a stored procedure before editing work someone else wrote

Frequently asked questions

Which SQL dialects are supported?＋

Standard SQL formatting that works across common dialects like PostgreSQL, MySQL, and SQL Server.

Are my queries private?＋

Yes — formatting happens locally in your browser, so internal schema stays with you.

Why does a query that runs fine in my database come back as a parse error?＋

Almost always the dialect. Square-bracket identifiers are SQL Server and backticks are MySQL, and each is a parse error under Standard SQL — SELECT [My Col] FROM [dbo].[Table] fails on the bracket and formats cleanly once the dialect is switched. Colon-style named parameters are the other frequent one: :userId stops the parser, while ?, @id and $1 pass through untouched. Curly quotes pasted from a document fail the same way. Leave a bracket unclosed and the underlying message runs to tens of thousands of characters of parser detail, all of which the page prints.

Does reformatting a query change what it does or how fast it runs?＋

Whitespace and keyword case are invisible to a SQL parser, so the statement means what it meant before. Two caveats. Recasing matters where identifiers are case-sensitive — an unquoted MySQL table name on Linux is — so a table named after a reserved word may stop resolving once it is shouted. And engines that key their plan cache on exact statement text, Oracle and SQL Server among them, treat a reformatted query as a new statement: same plan, but a fresh parse and another cache entry. Neither is a reason to avoid formatting, only not to reformat generated SQL in a hot path.

Should SQL keywords be uppercase or lowercase?＋

The uppercase convention predates syntax highlighting: on a monochrome terminal, case was the only thing separating keywords from column names. Editors do that job now, which is why plenty of teams have moved to lowercase. Neither is more correct. What matters is picking one and stopping, because a diff full of case changes buries the single line that actually changed — which is why reformatting a file on the day you send it for review is a bad idea. The Unchanged setting is there for that: reindent someone else's query to read it, without also claiming their casing as your own.

Can I format dbt models or Jinja-templated SQL?＋

No. A template tag is not SQL, so the parser stops at the first brace and reports a parse error. The workable routes are to format the compiled output — dbt writes real SQL into target/compiled, which pastes in cleanly — or to use a formatter built for templates, such as sqlfmt or sqlfluff with its Jinja templater, inside the project itself. The same goes for Airflow macros and similar interpolation. Swapping one or two tags for literal placeholders, formatting, and putting them back works on a short query and goes wrong on a long one.

Why is every value in my IN list on its own line?＋

Because a parenthesised expression that would run past a fixed width is broken one item to a line, and that width is not adjustable here — a short list stays inline as IN (1, 2, 3) while twenty numbers become twenty lines. It is ugly, and also a signal. A hand-written list of a few hundred literals is usually better as a join against a temporary table or a values list, and engines cap it anyway: Oracle refuses more than a thousand expressions in one IN clause. If the list came from somewhere else, format it and live with the length.

Is a SQL formatter the same as a linter or a validator?＋

No, and expecting a syntax check is the usual disappointment. Formatting reflows whitespace: it has no connection to your database and no knowledge of your schema, so a query against a table that does not exist formats perfectly. It parses loosely enough that a trailing comma before FROM is tidied rather than flagged. A linter such as sqlfluff applies rules — naming, ambiguous references, missing aliases — and only a real connection or an EXPLAIN will tell you a query is valid. What you learn incidentally: a query that will not parse at all is genuinely malformed for that dialect.