SQL Formatter: Format SQL Queries Online
Format SQL queries with readable spacing and indentation. Paste a query to inspect its structure before reviewing or sharing it.
SQL Formatter & Beautifier workspace
Input SQL Statement
Formatted SQL Result
Result will appear here...
Features
SQL Formatting
Beautify SQL queries with proper indentation and structure
Multiple Dialects
Support for MySQL, PostgreSQL, SQL Server, Oracle, and more
No Registration
100% free - no signup or account required
Keyword Casing
Uppercase, lowercase, or preserve original keyword casing
Minify Option
Compress SQL queries for optimized storage and transfer
Instant Processing
Real-time formatting with customizable output
SQL Formatter: Beautify and Minify Queries in Your Browser
Format SQL queries with readable spacing and indentation. Paste a query to inspect its structure before reviewing or sharing it. Formatting makes SQL easier to scan; it does not execute the query or prove that it is valid for your database dialect. Review strings, comments, and dialect-specific clauses, then validate the query against the intended database before running it.
How to use the SQL formatter
- Paste your SQL into the input box, or type a query directly.
- Pick a dialect label — Standard, MySQL, PostgreSQL, SQLite, T-SQL, or PL/SQL — for your own reference.
- Choose keyword casing: UPPERCASE for the common convention, lowercase, or Preserve to leave casing as-is.
- Set the indent size anywhere from 1 to 8 spaces (the default is 2).
- Press Format to beautify, or Minify to collapse the query to one line and strip comments.
- Click Copy to send the result to your clipboard, or Download to save a
.sqlfile.
How SQL formatting works (and why casing is safe)
SQL keywords are case-insensitive under the ANSI/ISO SQL standard, so SELECT, select, and Select all run identically. That is why a formatter can safely re-case keywords: it changes appearance, not behavior. The widely used SQL style guide by Simon Holywell recommends UPPERCASE reserved words (SELECT, WHERE, JOIN) with lowercase snake_case identifiers, so keywords stand out from your table and column names.
This tool is a beautifier, not a parser. It normalizes whitespace, inserts a newline before every major keyword (SELECT, FROM, WHERE, the JOIN family, GROUP BY, ORDER BY, and more), indents AND, OR, and ON conditions one level deeper, and tracks parenthesis depth to indent subqueries and CTEs. It re-cases only the keywords on its fixed list — your identifiers, string literals, and dialect quoting are left exactly as typed.
"Always capitalise the SQL reserved words... and make sure they are clearly separated from variable names."— Simon Holywell, SQL Style Guide
Worked examples: input → output
Format · UPPERCASE · 2-space indent
Input:
select id, name from users where active = 1 order by name
Output:
SELECT id, name FROM users WHERE active = 1 ORDER BY name
Format · JOIN with ON indented one level
SELECT u.id, o.total FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'
Minify · comments and whitespace stripped
Input:
SELECT id -- primary key FROM users
Output:
SELECT id FROM users
Edge case · keywords used as column names
The casing pass matches whole words from a fixed keyword list. A column literally named order, key, count, or end will be re-cased and pushed onto a new line as if it were a keyword. If you have identifiers that collide with reserved words, quote them (MySQL `order`, PostgreSQL "order", T-SQL [order]) or use Preserve casing to avoid surprises.
Identifier quoting by SQL dialect
Quoting an identifier (a table or column name) differs per database. The formatter preserves whichever character you use — this table is the reference for getting it right in each engine.
| Dialect | Identifier quote | String literal quote | Example |
|---|---|---|---|
| MySQL / MariaDB | Backticks ` | Single ' (double also OK) | `order` |
| PostgreSQL | Double " | Single ' only | "order" |
| T-SQL (SQL Server) | Brackets [ ] | Single ' | [order] |
| SQLite | Any: ", [ ], ` | Single ' | "order" |
| Standard / ANSI SQL | Double " | Single ' | "order" |
Source: ANSI SQL uses double quotes for identifiers and single quotes for string literals; MySQL adds backticks, T-SQL adds square brackets.
The dialect dropdown is a label, not a parser
Honest detail most SQL beautifiers gloss over: the dialect selector here changes nothing about the formatting logic. All six options (Standard, MySQL, PostgreSQL, SQLite, T-SQL, PL/SQL) run the same whitespace-and-keyword engine. It re-cases against a fixed list of roughly 90 reserved words and indents by clause and parenthesis depth — it does not understand backticks vs brackets, validate syntax, or rewrite dialect-specific constructs. The upside: your dialect-specific quoting and functions pass through untouched.
Two more real limits worth knowing: indentation is capped at 1–8 spaces (default 2), and input is accepted up to 10MB — far past any hand-written query. For deep schema or data validation, format here for readability, then run the SQL against your actual database.
Why formatted SQL reduces bugs in review
A query on one line hides its logic. Once each clause sits on its own line and JOIN conditions are indented, a reviewer can see at a glance whether the join key is correct, whether a WHERE filter is missing, or whether an unexpected OR widens the result set. Consistent casing and indentation also shrink diff noise, so code review focuses on real logic changes instead of whitespace. That is the same readability principle behind formatting JSON and XML before review.
Related data & developer tools
Beautify and validate query result payloads
JSON DiffCompare two API responses field by field
JSON Schema GeneratorDerive a schema from sample data
JSON to TypeScriptType a query result for your code
CSV ↔ JSON ConverterReshape exported table data
JSON ↔ YAML ConverterConvert between config formats
YAML ValidatorCheck config syntax errors
XML FormatterPretty-print XML documents
UUID GeneratorGenerate unique database keys
Base64 EncoderEncode data for transport
Case ConverterSwitch identifiers to snake_case
Guide: JSON ValidationFormat and validate data the right way
Guide: JSON vs YAML vs XMLCompare the major data formats
All ToolsBrowse the full Toolk hub
Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.
Frequently asked questions
Is re-casing keywords safe, or can it break my query?
Safe for keywords: SQL reserved words are case-insensitive under the ANSI/ISO standard, so rewriting select as SELECT changes appearance only. The tool re-cases solely against its fixed list of roughly 90 keywords — identifiers and string literals pass through untouched — though a column literally named order or count will be treated as a keyword, so quote such names or use Preserve casing.
Does the dialect dropdown change the formatting engine?
No, and that is deliberate honesty: Standard, MySQL, PostgreSQL, SQLite, T-SQL, and PL/SQL all run the same whitespace-and-keyword logic. The formatter does not parse backticks versus brackets or validate syntax — which also means your dialect-specific quoting and functions survive formatting untouched.
Do my queries or schema names get sent to a server?
No. Formatting, minifying, and casing run locally in your browser tab, and copy/download use native browser APIs — tool input is not sent to Toolk. Toolk's page analytics never receive your SQL, so proprietary schemas are safe to paste.
What does Minify remove exactly?
Both comment styles — single-line -- remarks and /* block */ notes — plus all extra whitespace, producing one compact line suitable for embedding or logging. When you need the opposite treatment for structured API payloads alongside your queries, Toolk's JSON formatter (/tools/json-formatter) beautifies result data the same way.