Free SQL formatter

1. Paste or upload your query. Drop raw SQL into the input box, or upload a .sql or .txt file — no size limit, no sign-up.
2. Pick a dialect. Choose Standard SQL, MySQL, PostgreSQL, SQLite, T-SQL, or BigQuery so dialect-specific syntax (backticks, TOP, array literals, and so on) parses correctly.
3. Set keyword case and indent. Toggle keywords to UPPERCASE, lowercase, or leave them as typed, and choose 2- or 4-space indentation.
4. Format, copy, or download. Click Format SQL to beautify the query, then copy the result or download it as a .sql file. Need the opposite? Hit Minify to collapse everything back to a single compact line.

Because formatting happens entirely on your device using the open-source sql-formatter library, there is no upload step, no waiting on a server, and no limit on how many queries you can format.

SQL is unusually forgiving about whitespace — a query with every clause jammed onto one line runs exactly the same as one that is neatly indented. That flexibility is exactly why formatting matters: nothing forces consistency, so without a formatter every developer, every ORM-generated query, and every copy-pasted snippet from Stack Overflow ends up looking different. A SQL beautifier gives you back that consistency for free.

• Readability. A query with ten joins and three subqueries is nearly impossible to audit as one line. Breaking it into clauses — one SELECT, one FROM, one WHERE per line — makes the logic visible at a glance.
• Faster debugging. When a query returns the wrong rows, a formatted layout makes it far easier to spot a misplaced AND/OR, a missing join condition, or an accidentally cross-joined table.
• Cleaner diffs and code review. Consistent formatting means pull requests show the actual logic change, not a wall of whitespace noise, which makes SQL migrations and stored procedures much easier to review.
• Easier onboarding. New team members read formatted queries faster than compressed ones, especially in analytics repos where queries are often hundreds of lines long.
• Safer copy-paste. Query builders, BI tools, and ORMs (Django, Sequelize, Prisma, Rails) frequently log or export SQL as one dense line. Formatting it before you paste it into a ticket, a Slack thread, or documentation keeps everyone on the same page.

There is no single official SQL style guide — every company and every open-source project seems to have slightly different conventions — but most style guides (Mozilla, GitLab, Simon Holywell's widely cited SQL Style Guide) converge on a few shared ideas that this tool applies:

• One major clause per line. SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, and LIMIT each start a new line, so the shape of the query is visible without reading every token.
• Consistent indentation. Columns in a SELECT list, conditions in a WHERE clause, and nested subqueries are indented relative to their parent clause — 2 spaces is the most common default, though 4 spaces is popular in enterprise codebases.
• Joins on their own line. Each JOIN (and its ON condition) gets its own line rather than being crammed after the previous clause, which matters most in queries with five or more joined tables.
• Predictable comma placement. Whether commas go at the end or the start of a line is mostly a matter of team preference — this formatter uses trailing commas, the more common convention in modern SQL style guides.
• Blank lines between statements. When a file contains multiple statements — a common pattern in migration scripts and seed files — a blank line (or two) between them keeps each query visually separate. You can control exactly how many with the “Lines between queries” setting.

Few SQL topics generate more good-natured disagreement than keyword casing. There is no technical reason to prefer one over another — SQL keywords are case-insensitive in every mainstream database — so the “right” choice comes down to team convention and readability preference.

Whichever you pick, the important thing is consistency across a codebase — mixed casing is what actually hurts readability, not the choice itself. This tool lets you switch instantly so you can match whatever convention your team already uses.

“SQL” is really a family of closely related but not identical languages. A query that parses fine in PostgreSQL can throw a syntax error in T-SQL, and vice versa. That is why this formatter lets you pick a specific dialect instead of assuming one universal grammar:

• Standard SQL — the ANSI baseline. Good default when you are not targeting a specific engine or are writing portable SQL.
• MySQL — supports backtick-quoted identifiers, LIMIT offset, count syntax, and MySQL-specific functions like IFNULL and GROUP_CONCAT.
• PostgreSQL — adds array types, JSONB operators (->, ->>), ILIKE, and window function extensions that other dialects don't recognize.
• SQLite — a lighter grammar with a few of its own quirks, like flexible typing and INSERT OR REPLACE.
• SQL Server (T-SQL) — uses TOP n instead of LIMIT, square-bracket [identifiers], and procedural extensions like DECLARE and BEGIN...END.
• BigQuery — Google's dialect adds backtick-quoted fully qualified table paths (`project.dataset.table`), STRUCT/ARRAY types, and its own set of analytic functions.

If a query fails to parse under the selected dialect, the tool still shows a best-effort formatted result along with a plain-language message — try switching dialects first, since a mismatched dialect is the most common cause of a parse error.

Beyond picking a dialect and a keyword case, a few habits separate genuinely readable SQL from SQL that is merely indented. Watch for these when you review formatted output:

• Burying join conditions. Writing joins as implicit comma-separated tables in the FROM clause with conditions tucked into WHERE was standard practice decades ago, but explicit JOIN ... ON syntax is far easier to format, read, and audit for accidental cross joins.
• Over-nesting subqueries. A formatter can indent a deeply nested subquery cleanly, but that doesn't make it easy to read. If a query needs three or more levels of nesting, a common table expression (WITH clause) usually communicates intent better and formats more predictably.
• Inconsistent aliasing. Mixing AS and bare aliases, or aliasing some columns but not others, makes formatted output look inconsistent even when indentation is perfect. Decide on one convention and apply it throughout the query.
• Ignoring line length. A single WHERE condition with six ANDs chained on one line defeats the purpose of formatting. Breaking boolean conditions onto their own lines — one predicate per line — keeps even complex filters scannable.
• Formatting after the fact, every time. Running a formatter once on a legacy file helps, but the real value comes from formatting consistently as part of your workflow — before every commit, or as a pre-commit hook — so formatting differences never show up as noise in a diff.

None of these are enforced by the SQL language itself, which is exactly why a formatter is useful: it takes team conventions that would otherwise live only in a style guide document and applies them automatically, every time, without a reviewer having to leave a comment about spacing instead of logic.

• Backend & data engineers clean up auto-generated ORM queries and long analytics queries before committing them to a repo.
• Analysts & data scientists tidy ad-hoc queries pulled from a BI tool or notebook before sharing them with a teammate.
• DBAs reformat queries pulled from slow-query logs to make them easier to read during performance tuning.
• Students & bootcamp learners use consistent formatting to build good habits early and make their own queries easier to debug.
• Technical writers format SQL examples for documentation, blog posts, and tutorials so code blocks look professional and are easy to scan.
• Interviewers & candidates paste interview SQL questions and answers into a shared format to reduce friction when reviewing solutions.

• Alias every joined table with something short and meaningful (o for orders, c for customers) — it keeps formatted output compact without sacrificing clarity.
• Format before you optimize. A cleanly indented query makes it far easier to spot a missing index candidate or an unnecessary subquery.
• Keep SELECT * out of production queries — list columns explicitly so a formatted diff actually shows which fields changed.
• For migration files with many statements, increase “Lines between queries” to make each statement easier to scan when reviewing a pull request.
• When in doubt about dialect, start with Standard SQL — it handles the common subset most queries use, and you can switch to a specific dialect only if formatting looks off.

Working with an actual database file instead of a raw query string? Try the online DB viewer to open a SQLite file and run SQL directly in your browser.

No — formatting is purely cosmetic. A query optimizer parses SQL into an execution plan long before whitespace, line breaks, or keyword casing come into play, so a beautifully formatted query and its single-line equivalent run identically and produce the same execution plan. What formatting changes is how quickly a human can read the query, which indirectly improves performance in a different way: well-formatted SQL is easier to review for missing indexes, unnecessary subqueries, or an accidental Cartesian product, all of which do affect real-world speed. In other words, formatting doesn't make a query faster by itself, but it makes the queries that are slow easier to spot.

The same logic applies to minifying. Collapsing a query down to one compact line — useful when embedding SQL in application code, logs, or a configuration file — has zero effect on how the database executes it. Minifying is purely about transport and storage convenience, not execution speed.

Yes. This tool formats every query entirely in your browser using the open-source sql-formatter JavaScript library — nothing you type or upload is ever sent to a server. That makes it safe to paste queries that reference real table names, column names, or business logic you would rather not send to a third party. It also means the tool keeps working offline once the page has loaded, with no rate limits and no account required.