SQL Formatter

Runs in browser Database

Beautify SELECT, INSERT, UPDATE, DELETE, CTEs, JOINs and subqueries into readable SQL. Choose keyword case, indent size and comma style.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.
Loading tool…

How to use SQL Formatter

  1. Paste one or more SQL statements.
  2. Select the dialect that matches your database and your preferred keyword case, indentation and comma style.
  3. The formatted SQL updates live; copy it or download it as a .sql file.

SQL Formatter features

  • Five dialects: MySQL/MariaDB, PostgreSQL, SQL Server, Oracle, SQLite
  • Uppercase, lowercase or preserved keyword casing (functions too)
  • Clause-per-line layout with indented SELECT lists, JOINs, AND/OR conditions
  • Subqueries, CTEs (WITH … AS), CASE expressions and VALUES lists are indented as blocks
  • Trailing or leading comma style; 2/4-space or tab indentation
  • Comments, string literals, quoted identifiers and parameters are preserved verbatim
  • Multiple statements are formatted separately with a blank line between them

SQL Formatter example

Format a one-line query

Input:

select id, name from users where active = 1 and role in ('admin','editor') order by name limit 10

Output:

SELECT
  id,
  name
FROM
  users
WHERE
  active = 1
  AND role IN ('admin', 'editor')
ORDER BY
  name
LIMIT 10

Frequently asked questions about SQL Formatter

Which SQL dialects are supported?

MySQL/MariaDB, PostgreSQL, SQL Server (T-SQL), Oracle and SQLite. The dialect controls how strings, quoted identifiers, comments and parameters are tokenised — for example backticks in MySQL, [brackets] in SQL Server and $$ dollar quotes in PostgreSQL.

Will formatting change what the query does?

No. Only whitespace and keyword casing change; identifiers, string literals, numbers and comments are preserved exactly.

Can I format several statements at once?

Yes. Statements separated by semicolons are formatted individually with a blank line between them.

How are subqueries and CTEs handled?

Subqueries in parentheses are placed on their own indented block, and WITH … AS (…) clauses are formatted the same way so the main query stays readable.

Does it work with stored procedures or PL/SQL blocks?

Procedural code (BEGIN … END blocks, IF/LOOP) is formatted on a best-effort basis; plain DML and DDL statements give the best results.

Technical notes

The formatter tokenises the input with a dialect-aware lexer (strings with '' or backslash escapes, "quoted", `backtick` and [bracket] identifiers, $$ dollar quotes, -- / # / block comments, ?, :name, @name and $1 parameters) and then applies a small layout engine: top-level clause keywords start a line and indent their content, JOIN/AND/OR start new lines, parentheses containing a statement become indented blocks and inline parentheses stay compact.

Multi-word keywords (GROUP BY, LEFT OUTER JOIN, IS NOT NULL, ON DUPLICATE KEY UPDATE …) are recognised as single phrases, so casing and line breaks are applied consistently.