SQL Formatter

What is a SQL formatter?

SQL is forgiving about whitespace, which is exactly why queries get messy. A statement that started as a quick SELECT grows joins, subqueries and a long WHERE clause until it is one sprawling, unindented line that nobody wants to read. A SQL formatter takes that raw query and reprints it with consistent indentation, line breaks and keyword casing, so the structure of the statement becomes obvious at a glance.

This tool formats your SQL live as you adjust the options, using a battle-tested parser that understands many database dialects. It runs entirely in your browser — no upload, no account, no network call — so it works offline and keeps your queries private.

How to use it

1. Paste your SQL into the input box, or click Sample to load an example query.
2. Pick your dialect from the dropdown so dialect-specific keywords are handled correctly.
3. Choose an indent — 2 spaces, 4 spaces, or a tab — and a keyword case (UPPER, lower, or keep as written).
4. The formatted output updates instantly below.
5. Toggle Minify if you instead want everything collapsed onto a single compact line.
6. Copy the result or download it as a .sql file.

Why formatting SQL matters

Readable SQL is maintainable SQL. When a query is consistently indented:

• Joins and subqueries line up, so you can see at a glance how tables relate and where a nested query begins and ends.
• The WHERE clause is scannable, making it easy to spot a missing condition or an accidental cartesian join.
• Code review is faster, because reviewers spend their attention on logic instead of deciphering layout.
• Diffs are smaller, since a well-formatted query stored in version control changes line-by-line rather than as one giant blob.

Teams that agree on a single SQL style — indent width, keyword case, where clauses break — get all of this for free. A formatter makes that style effortless to apply and impossible to forget.

Keyword case: upper, lower or preserve

There is no functional difference between SELECT and select — SQL keywords are case-insensitive. The choice is purely about readability and house style:

• UPPERCASE keywords are the traditional convention and make keywords stand out clearly from table and column names. This is the most common style in documentation and many codebases.
• lowercase keywords are popular in modern analytics stacks (think dbt projects) where the whole query reads more like prose.
• Preserve leaves casing exactly as you typed it, which is useful when you are formatting someone else's code and do not want to impose a style.

Pick one and apply it consistently — mixing cases within a project is the only genuinely wrong answer.

Dialect differences

While the core of SQL is standardized, every database adds its own flavor, and a formatter that knows the dialect handles them more gracefully:

• PostgreSQL has rich type casts (::text), array syntax and RETURNING clauses.
• MySQL / MariaDB use backticks for identifiers and have their own functions and LIMIT behavior.
• BigQuery and Snowflake add cloud-warehouse extensions like QUALIFY, struct/array types and unusual function names.
• SQLite is deliberately minimal, while T-SQL (SQL Server) and PL/SQL (Oracle) carry large procedural extensions.

Choosing the matching dialect tells the formatter which words are keywords and how certain constructs should break, producing cleaner output. If you are unsure, Standard SQL is a safe default that works well for everyday queries.

A note on privacy: do not paste production queries into ad-heavy sites

This deserves its own section because it is a real risk. Many free SQL formatters are wrapped in aggressive advertising and analytics, and some send your query to a server to format it. When that query contains internal table names, business logic in the WHERE clause, or even sample values, you are leaking information about your data model to third parties you never chose.

Pageonaut formats locally in your browser. Your SQL never travels over the network, is never logged, and disappears the moment you close the tab. That makes it safe to clean up the kind of real, production-shaped queries you would never want on someone else's server. There is no hidden round-trip, no telemetry attached to your query text, and no third-party script reading the contents of the editor. If your company has a policy against pasting internal schema details into external services, a tool that processes everything on-device is the only kind that can honestly satisfy it — and you can verify the behavior simply by disconnecting from the network and watching it keep working.

Tips for cleaner SQL

• Format before you commit. Run queries through the formatter before saving them to version control so your team sees consistent, reviewable diffs.
• One clause per line for big queries. Long SELECT lists and WHERE conditions are far easier to scan when each item sits on its own line — exactly what formatting gives you.
• Keep a house style. Agree on dialect, indent and keyword case once, then let the tool enforce it.
• Minify only at the edges. Use minify for transport or embedding, but keep the readable, formatted version as your source of truth.
• Format generated SQL too. ORMs and query builders emit dense one-liners; pasting them here is a quick way to understand what your code is actually sending to the database.

Free, local and login-free

There is no sign-up, no paywall and no upload. Paste your query, pick a dialect, choose how you want it laid out, and copy or download the result. Everything happens on your machine, so you get clean SQL without handing your queries to anyone. When your work spills into other formats, the same in-browser approach powers the JSON formatter for API payloads and the Base64 encoder / decoder for encoded values.