SQL Formatter

What is SQL Formatter?

SQL Formatter reformats poorly indented or single-line SQL queries into a clean, readable structure with proper line breaks and indentation. It helps with code reviews and debugging complex queries that involve JOINs and subqueries. It supports major SQL dialects such as MySQL, PostgreSQL, and SQLite, and lets you configure indent width and keyword casing.

When this comes in handy

• A query pulled from app logs or a DB tool is squeezed onto one line: ORM-generated queries and slow query logs are often output without any line breaks — paste one in and it’s reformatted into a structure you can actually follow.
• You need to untangle a query with several JOINs or nested subqueries: each clause (SELECT, FROM, WHERE, JOIN, and so on) is broken onto its own line and indented, making it easy to see which tables are joined on which conditions.
• Your team wants consistent SQL style (keyword casing, indent width) across reviews: the uppercase/lowercase keyword options combined with 2-space, 4-space, or tab indentation remove that source of review nitpicks.
• You want to confirm a query parses correctly under the dialect of the database you actually use: pick the Dialect that matches your DBMS to catch dialect-specific syntax issues (like backtick-quoted identifiers) early.

Usage examples

Example 1: Formatting a SELECT with a JOIN

Input (single-line SQL):

select u.id, u.name, o.total from users u join orders o on u.id = o.user_id where o.total > 100 order by o.total desc

Formatted (2-space indent, uppercase keywords):

SELECT
  u.id,
  u.name,
  o.total
FROM
  users u
  JOIN orders o ON u.id = o.user_id
WHERE
  o.total > 100
ORDER BY
  o.total DESC

Each clause — SELECT, FROM, JOIN, WHERE, ORDER BY — starts on its own line, with selected columns and join conditions indented underneath, so you can quickly grasp the shape of the whole query.

Example 2: Switching indentation to tabs

Setting “Indent” to “Tab” reformats the same input using tab characters instead of spaces — handy when you want the output to match your editor’s tab-width setting.

SELECT
	u.id,
	u.name
FROM
	users u

Example 3: Normalizing keyword case

Input:

SELECT id, name FROM users WHERE active = TRUE

Setting “Keyword case” to “Lowercase” normalizes SELECT, FROM, and other keywords to lowercase:

select
  id,
  name
from
  users
where
  active = true

Choosing “Preserve” leaves the original keyword casing (including any mixed case) exactly as typed.

Example 4: How dialect affects the result

Consider a query using MySQL-style backtick-quoted identifiers:

SELECT `user`.`id`, `user`.`name` FROM `user` WHERE `user`.`status` = 1

With the Dialect set to “MySQL” or “MariaDB” this formats without issue. With “Standard SQL” selected, backticks aren’t a recognized identifier quoting style and formatting can fail with an error. Matching the Dialect to your actual database lets you catch this kind of dialect-specific syntax difference early.