SQL Formatter & Beautifier

SQL Formatting Guide

SQL formatting - also known as beautifying or pretty printing - re-indents a query so each clause (SELECT, FROM, WHERE, JOIN, ORDER BY) starts on its own line with consistent indentation and keyword casing, making it easy to read and edit. Because SQL syntax differs slightly between database engines, this tool parses your query using the dialect you choose, so dialect-specific syntax like TOP, backtick-quoted identifiers, or :: type casts is handled correctly instead of producing broken or misleading output.

Why Use a SQL Formatter?

SQL pulled from an ORM, a slow-query log, a teammate's Slack message, or a BI tool is often a single hard-to-scan line. This tool solves that in one place:

• Readability for code review: Consistently indented SQL in a pull request gets reviewed more carefully than a one-line blob.
• Debugging long queries: Break apart queries extracted from application logs, ORMs (Hibernate, Sequelize, Prisma), or BI tools to see exactly what's being run.
• Team consistency: Apply the same indent size and keyword casing across a codebase without retyping it by hand.
• Dialect-aware correctness: Formatting with the right dialect avoids "looks right but breaks on your DB" mistakes from generic, one-size-fits-all formatters.
• Zero install: Works entirely in your browser - no extensions, plugins, or sign-up required.

SQL Formatter in Action

Here's a quick example of the same query before and after running it through this tool:

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

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

This Tool vs. Manual Formatting

Formatting SQL by hand or relying on a one-size-fits-all formatter both have downsides this tool avoids:

This Tool vs. Other Online SQL Formatters

Common Use Cases for SQL Formatting

• Cleaning up copy-pasted SQL: A query copied from a Slack message, ticket, or Stack Overflow answer is often a single unreadable line. Format it before reusing it.
• Reading log-extracted queries: Format SQL pulled from application logs or slow-query logs to see what's actually running against your database.
• Standardizing ORM output: Beautify SQL generated by an ORM before including it in a code review or design doc.
• Writing documentation: Prepare readable SQL examples for docs, blog posts, or Stack Overflow answers.
• Checking dialect syntax: Quickly confirm whether a query should use LIMIT or TOP for your target database.

What Changes When Formatting

• Clause line breaks: each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY) starts on its own line.
• Column lists: comma-separated columns under SELECT or GROUP BY are placed one per line.
• Conditions: AND/OR conditions in WHERE are broken onto their own indented lines.
• Keyword casing: normalized to upper or lower case, or left as-is, based on the Keyword case option.
• Indentation: applied consistently using your chosen indent width (2/4 spaces or a tab).
• Query logic: string literals, comments, and identifiers are left untouched - only whitespace and casing change, the query's behavior never does.

How to Use This Tool

1. Paste your SQL - or click "Load sample" to try it with example code.
2. Choose a SQL dialect - MySQL, PostgreSQL, SQL Server, Oracle, and more, so dialect-specific syntax parses correctly.
3. Pick an indent size and keyword case - 2 spaces, 4 spaces, or tabs, with upper, lower, or preserved keyword casing.
4. Click Format - the result appears in the output box, with character counts for both versions.
5. Copy the result - click Copy to place it on your clipboard.

SQL Formatting Best Practices

• Always pick the correct dialect: generic "Standard SQL" parsing can fail on dialect-specific keywords like TOP, QUALIFY, or ::type casts.
• Keep one clause per line: for long queries, even if your team's style is otherwise compact - it makes diffs and reviews easier.
• Be consistent with keyword casing: across a codebase - commonly, uppercase keywords with lowercase identifiers.
• Format before reviewing, not after: readable SQL in a pull request gets reviewed more carefully than a single dense line.
• Don't expect logic fixes: formatting only changes whitespace and casing - it never changes what a query actually does.

Frequently Asked Questions