SQL prettify and format

Format SQL instantly

Paste SQL, choose dialect, keyword case, and indentation style, then copy the formatted output

Last updated: February 6, 2026

CreatorFrank Zhao

Dialect

Keyword case

Indent style

Your SQL query

Prettify version of your query

SELECT
  field1,
  field2,
  field3
FROM
  my_table
WHERE
  my_condition;

SQL is easy to write quickly and hard to read later. A good formatter makes your queries consistent, reviewable, and safer to change. This guide shows what the SQL Prettify tool does, how to use it in seconds, and how to pick the right options (dialect, keyword case, and indentation style).

→Introduction / overview
→How to use (quick start)
→Step-by-step examples
→Real-world use cases
→Common scenarios
→Tips & best practices
→Calculation method / formulas
→Related concepts
→FAQs, limitations, sources

Introduction / overview

The SQL Prettify and Format tool takes messy SQL and produces a clean, consistent layout. It helps you spot mistakes faster, review changes in pull requests, and keep queries readable across a team.

Everything runs locally in your browser: paste SQL, choose options, copy the formatted query.

Who is this for?

Data analysts cleaning up reports and dashboards.
Developers reviewing query changes or generating migrations.
Anyone debugging a complex query with nested joins and subqueries.

If you also work with JSON and URLs, you may like our JSON prettify and format and URL encoder for quickly cleaning inputs during debugging.

How to use / quick start

1Choose the SQL Dialect that matches your database (for example, PostgreSQL vs BigQuery).
2Pick a Keyword case style. If your team prefers $\text{SELECT}$ , choose “UPPERCASE”. If you want to keep existing casing, use “Preserve”.
3Set the Indent style (Standard is a safe default; Tabular styles try to align columns).
4Paste your SQL into “Your SQL query”. The formatted output appears instantly on the right.
5Click copy, then paste the result into your editor, BI tool, or PR comment. Use “Reset” if you want to return to defaults.

Quick sanity check (with a tiny “math” example)

Many formatting styles use a fixed indentation width (often $w = 2$ spaces). If your query has nested blocks, the visual indent is roughly “levels times width”.

I = w\,L

=

2\times 4

=

8\ \text{spaces}

If you see indentation that looks “too deep”, try a different indent style, or reduce nesting (for example, by extracting a subquery into a CTE).

How to use (step-by-step examples)

Example 1: Fix a one-line query

Input (messy):

select a,b,c from orders where created_at>='2026-01-01' and status in ('paid','shipped') order by created_at desc;

Suggested options: Dialect “Standard SQL”, Keyword case “UPPERCASE”, Indent style “Standard”.

Result: the formatter places each clause (SELECT, FROM, WHERE, ORDER BY) on clean lines, so reviewing logic becomes easier.

Example 2: Make indentation consistent in a nested query

You paste a query with uneven spacing and mixed casing.

Use “Tabular left” if you want aligned columns, or “Standard” if you care more about compact readability. A helpful mental model is that indentation accumulates by nesting level.

I = w\,L

If your expected nesting level is $L=3$ and your style uses $w=2$ , the visible indentation is about $I=6$ spaces.

Real-world examples / use cases

Use case: safer code reviews

Background: reviewers miss logic changes when whitespace is inconsistent.

Input: a query with nested conditions and joins (dialect PostgreSQL).

Result: formatted output reduces “diff noise”. If you indent by $w=2$ spaces and the maximum nesting is $L=4$ , the deepest blocks line up at about $I=8$ spaces.

How to apply: format before committing or pasting into a PR comment.

Use case: BI dashboards and saved queries

Background: dashboards are maintained for months (or years).

Input: BigQuery SQL copied from an ad-hoc notebook.

Result: consistent keywords and indentation make it easier for someone else to pick up later.

How to apply: format before saving, then store the formatted SQL alongside a short description.

Use case: sharing reproducible inputs

Background: you want to send a colleague the exact query + settings.

Input: SQL + your chosen options (dialect, keyword case, indent style).

Result: a shareable URL. (If the SQL is very large, sharing without results is usually better.)

How to apply: use Share, then decide whether to include results.

Tip: if you need to share SQL in an environment that only accepts a single line, you can pair this tool with our URL encoder or Base64 string encoder/decoder depending on your workflow.

Common scenarios / when to use

Before a PR or code review

Useful: reduces noisy diffs and clarifies intent.

Not ideal: if your project enforces a different SQL style guide.

Cleaning dashboard queries

Useful: consistent formatting makes long-term maintenance easier.

Not ideal: if the BI tool rewrites SQL on save anyway.

Debugging a failing query

Useful: makes joins/filters visually separable.

Not ideal: if the query is not valid SQL yet (fragments).

Standardizing team style

Useful: choose a consistent keyword case across a codebase.

Not ideal: if you need highly customized formatting rules.

Sharing SQL in chat or tickets

Useful: formatted SQL is easier to skim and quote.

Not ideal: if the platform collapses whitespace aggressively.

When it might not fit

Useful: quick readability.

Not ideal: vendor-specific syntax not covered by the selected dialect.

Tips & best practices

Practical tips

Start with Dialect “Standard SQL” if you’re unsure, then switch to your exact database once you know.
If a query looks “too wide”, try Standard indentation instead of Tabular indentation.
Prefer CTEs for readability when nesting gets deep (a human-friendly alternative to extreme indentation).
When sharing, consider excluding results if your SQL contains sensitive identifiers.
Pair with Basic auth generator when you’re testing APIs and want clean SQL snippets in your notes.

Calculation method / formula explanation

A SQL formatter is a deterministic transformer: it reads your input string and returns a new string with normalized whitespace, line breaks, and keyword casing.

S_{\text{out}} = F\left(S_{\text{in}};\ d,\ k,\ i\right)

What the symbols mean

$S_{\text{in}}$ : the raw SQL you paste.
$S_{\text{out}}$ : the formatted SQL you copy.
$d$ : dialect (e.g., PostgreSQL, MySQL).
$k$ : keyword case (upper/lower/preserve).
$i$ : indentation style (standard or tabular alignment).

If you want a quick way to reason about indentation depth, you can think in terms of indentation width $w$ and nesting level $L$ :

I = w\,L

=

2\times 3

=

6\ \text{spaces}

Related concepts / background info

What is a “dialect”?

SQL is a family of languages. Most databases share common syntax, but details differ (functions, quoting rules, LIMIT/OFFSET behavior, and more). Selecting the right dialect helps the formatter interpret tokens more accurately.

Keyword case

Keyword case affects readability. Some teams prefer $\text{UPPERCASE}$ for SQL keywords, while others prefer a lighter look. “Preserve” is useful when you’re formatting someone else’s query and want minimal semantic changes.

Tabular indentation

Tabular styles try to align columns and aliases to create a “table-like” look. It can be great for SELECT lists, but may look wide on small screens.

FAQs, limitations, sources

Why does choosing a dialect matter?

Dialects change token rules and functions. If formatting looks odd, switch the dialect to match your target database first.

Does formatting change what the query returns?

Formatting is intended to change whitespace and casing only. Still, you should treat the formatted output as code: run it in a safe environment and verify results.

My SQL is incomplete — why can’t it format?

Most formatters expect syntactically valid SQL. If you have fragments, try adding missing parts temporarily (for example, a placeholder table name) to get a clean layout.

How should I share sensitive SQL?

Prefer sharing without results, and remove secrets, customer identifiers, or internal table names whenever possible.

Can I use this as a SQL validator or security tool?

No. It’s a formatter, not a validator, query planner, or security scanner.

Limitations / disclaimers

This tool helps with readability, but it does not guarantee query correctness, performance, or compliance. Always test important queries and follow your organization’s data handling policies.

External references / sources

Related Calculators

HTML WYSIWYG editor

Edit rich text in a simple WYSIWYG editor and copy Prettier-formatted HTML instantly. Runs locally in your browser.

Try Now

Phone parser and formatter

Parse, validate, and format phone numbers. Get the country, calling code, type, and common formats like E.164 and RFC3966. Runs locally in your browser.

Try Now

Encode/decode URL-formatted strings

Encode and decode URL-formatted strings (percent-encoding). Runs locally in your browser with instant copy.

Try Now

URL parser

Parse a URL into its constituent parts (protocol, username, password, hostname, port, path, params). Runs locally in your browser with instant copy.

Try Now

Fraction to Percent Calculator

Convert fractions to percentages and vice versa instantly

Try Now

Grams to Tablespoons Converter

Convert grams to tablespoons for any ingredient instantly. Perfect for cooking and baking with support for multiple ingredients.

Try Now