Skip to content

SQL Formatter

Paste a SQL query and get it reformatted with each clause — SELECT, FROM, WHERE, JOIN, GROUP BY — on its own line and correctly indented, including nested subqueries. Built on a real SQL parser, not a regex pass that puts a newline before every uppercase-looking keyword and breaks on the first subquery.

  • 6 SQL dialects: standard, MySQL, PostgreSQL, SQLite, T-SQL, PL/SQL
  • Correctly indents nested subqueries and joins
  • Configurable keyword case and indent width
  • Clean error messages with line and column
  • Runs fully client-side

Formatter

Parsed locally, nothing uploaded

Output

How to format SQL

  1. 01

    Paste the query

    Any length — a simple SELECT or a query with joins and subqueries.

  2. 02

    Pick the dialect

    Match it to where the query actually runs — quoting rules differ (backticks in MySQL, double quotes in PostgreSQL).

  3. 03

    Adjust case and indent, if wanted

    Keyword case defaults to uppercase; indent defaults to 2 spaces.

Why this needed a real parser, not a regex pass#

A regex-based SQL "formatter" — one that just inserts a newline before every SELECT, FROM, WHERE it spots — breaks the moment those words appear somewhere they are not a clause keyword: inside a string literal, a column named from_date, or a subquery whose own clauses need a deeper indent level than the outer query's. Correctly formatting SQL means actually parsing its grammar (understanding what is a subquery, what is nested inside what, where one clause ends and the next begins) — hard enough that this tool uses a dedicated SQL parsing library instead of attempting it by hand, the same reasoning already applied to YAML on this site.

Why the dialect selector matters#

SQL isn't one language — MySQL quotes identifiers with backticks, PostgreSQL and standard SQL use double quotes, and each dialect has its own extensions and reserved words. Picking the wrong dialect can cause valid syntax to be misread or database-specific syntax to fail entirely. Match the dialect to whichever database the query is actually meant to run against.

Uppercase keywords: a convention, not a requirement#

SQL keywords are case-insensitive to every database engine — select and SELECT execute identically. Uppercasing them (the default here) is a long-standing readability convention that visually separates SQL syntax from table and column names in mixed-case queries; "preserve" mode is available for anyone who deliberately writes lowercase and wants that kept.

Frequently asked questions

Why not just use a regex to add line breaks before keywords?

Because that breaks the moment a keyword appears somewhere it is not actually a clause — inside a string, a column name like from_date, or a nested subquery that needs deeper indentation than the outer query. This tool uses a real SQL parser instead of guessing from keyword position.

Does the dialect choice actually matter?

Yes — quoting conventions and reserved words differ by database (backticks in MySQL, double quotes in PostgreSQL and standard SQL, for example). Matching the dialect to where the query actually runs avoids misreading valid syntax.

Does SQL require uppercase keywords?

No — SQL keywords are case-insensitive to every engine. Uppercase is a readability convention this tool defaults to; "preserve" keeps whatever casing you originally typed.

Is my SQL sent anywhere?

No. Formatting runs entirely in your browser — nothing is uploaded.

Developers

UUID Generator

Generate cryptographically random UUID v4 or time-ordered UUID v7, in bulk.

Developers

Base64 Encoder & Decoder

Encode and decode Base64 with correct UTF-8 handling, including the URL-safe alphabet.

Developers

ULID Generator

Generate ULIDs — sortable by creation time like UUID v7, but Crockford Base32 instead of hex.