Skip to main content

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...

Status: Verified Safe Local Processing
Latency: Zero-Latency SQL Engine

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

  1. Paste your SQL into the input box, or type a query directly.
  2. Pick a dialect label — Standard, MySQL, PostgreSQL, SQLite, T-SQL, or PL/SQL — for your own reference.
  3. Choose keyword casing: UPPERCASE for the common convention, lowercase, or Preserve to leave casing as-is.
  4. Set the indent size anywhere from 1 to 8 spaces (the default is 2).
  5. Press Format to beautify, or Minify to collapse the query to one line and strip comments.
  6. Click Copy to send the result to your clipboard, or Download to save a .sql file.

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.

DialectIdentifier quoteString literal quoteExample
MySQL / MariaDBBackticks `Single ' (double also OK)`order`
PostgreSQLDouble "Single ' only"order"
T-SQL (SQL Server)Brackets [ ]Single '[order]
SQLiteAny: ", [ ], `Single '"order"
Standard / ANSI SQLDouble "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.

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.

Need a different tool?

Browse all 103 browser-based tools (103 currently marked free), or tell us what useful utility we should build next.

Browse all tools