This free SQL formatter takes a query in any shape — a single unbroken line pasted from a slow query log, a cramped one-liner copied out of an ORM debug panel, or a hand-written query with inconsistent spacing — and rebuilds it with consistent indentation, one clause per line, and aligned column lists. It does this by actually tokenizing the query character by character, not by running a handful of regular expressions against the raw text, so it correctly leaves commas inside function calls and subqueries alone while still breaking the top-level SELECT list onto separate lines.
At Arb Digital we read and write a lot of SQL — building reporting queries for client dashboards, debugging slow joins during a site migration, or sanity-checking a query a client's in-house developer sent over. A dependable SQL formatter that runs instantly in the browser, with no upload and no account, is one of those small tools that saves real minutes every single day.
What This SQL Formatter Does
Paste a query into the box above and click Format SQL. The tool tokenizes your input — splitting it into keywords, identifiers, quoted strings, numbers, comments, and punctuation — and then reassembles those tokens using a fixed set of layout rules: major clauses such as SELECT, FROM, WHERE, GROUP BY, ORDER BY, and LIMIT each start a new line; every join type (LEFT JOIN, INNER JOIN, RIGHT JOIN, and their OUTER variants) gets its own line; AND and OR inside a WHERE clause drop to a new, indented line; and commas that separate items in the top-level SELECT list each start a fresh line so a wide column list is easy to scan top to bottom.
Because the tool works from real tokens rather than blind text replacement, it correctly distinguishes a comma inside COUNT(o.id) or an IN (1, 2, 3) list — which should stay on one line — from a comma separating two columns in the SELECT clause, which should not. This is the single biggest failure point of naive "search and replace" SQL formatters, and it's the first thing we tested when building this one.
How to Use It
- Paste your query. Any dialect of SQL works reasonably well — MySQL, PostgreSQL, SQL Server, and SQLite all share the same core clause structure this tool understands.
- Choose a keyword case. UPPERCASE keywords is the traditional convention and the default here; lowercase is common in newer style guides and ORMs.
- Choose an indent size. 2 spaces is the most common convention in modern SQL style guides; 4 spaces reads a little more spacious on wide monitors.
- Click Format SQL. The formatted query appears instantly in the output box below, along with quick stats — line count, keywords recognized, and output size.
- Copy the result with one click and paste it into your migration file, code review comment, or documentation.
The Formula — How the Tokenizer Works
The tool runs a small hand-written lexer over the input string. It walks the text one character at a time and classifies each chunk into one of a handful of token types: whitespace (skipped), line comments starting with --, block comments wrapped in /* */, single-quoted string literals (correctly handling escaped '' quotes inside a string), double-quoted or backtick-quoted identifiers, numbers, bare words, and punctuation such as commas, parentheses, and the semicolon.
Once the text is broken into tokens, a second pass merges adjacent word tokens that form multi-word keywords — GROUP BY, ORDER BY, LEFT OUTER JOIN, INSERT INTO, UNION ALL, and similar phrases — so the formatter treats them as a single logical unit rather than two separate keywords that happen to sit next to each other. A third pass then applies layout rules: clause-starting keywords force a line break at the base indent level, join keywords force a line break at the same level, AND/OR inside a condition force a line break one level deeper, and a running parenthesis-depth counter makes sure none of that line-breaking logic fires while the formatter is inside a function call, a subquery, or an IN (...) list. This approach — tokenize, classify, then lay out — is the same general strategy used by production-grade SQL formatters and pretty-printers, and it is what makes the output reliable across a wide range of real queries rather than just the one example you tested with.
For a broader reference on conventional SQL formatting choices — comma placement, keyword casing, indentation depth, and naming — see Simon Holywell's widely cited SQL Style Guide, and for the authoritative clause-by-clause grammar of a modern SQL dialect, the PostgreSQL SELECT documentation is an excellent reference.
Why Readable SQL Matters
A query that works is not the same thing as a query someone else can safely change six months later. Dense, single-line SQL hides structure: it's hard to tell at a glance which table a WHERE condition applies to, whether a JOIN is INNER or LEFT, or how many columns a SELECT actually returns without scrolling sideways. Formatted SQL turns those questions into something you answer by scanning down a column of lines rather than parsing a wall of text. That matters most during code review, when a reviewer has seconds — not minutes — to spot a missing join condition or an accidental cross join, and during incident response, when someone unfamiliar with a query needs to understand it fast under time pressure.
It also matters for diffs. When SQL lives in a migration file or a version-controlled query library, a consistent layout means that a small logical change — adding one WHERE condition, say — produces a small, readable diff. A single-line query, by contrast, often produces a diff that touches the entire line even when only a few characters changed, which makes code review needlessly noisy.
Keyword Casing: UPPERCASE vs lowercase
Both conventions are common in real codebases, and this SQL formatter supports either. UPPERCASE keywords is the older, more traditional style — it visually separates SQL syntax from table and column names at a glance, which is genuinely useful in dense queries with many identifiers. Lowercase keywords have become more common as teams standardize on lowercase table and column names throughout, valuing visual consistency over the syntax/data contrast that uppercase provides. Neither is objectively correct; what matters more than the choice itself is applying it consistently across a codebase, which is exactly the kind of mechanical consistency a formatter enforces far more reliably than manual typing ever will.
Indentation and Clause Structure
This formatter places each major clause — SELECT, FROM, every JOIN variant, WHERE, GROUP BY, HAVING, ORDER BY, and LIMIT — flush against the left margin of the query, with everything inside a clause indented one level in. This mirrors the layout recommended by most SQL style guides and is close to what you'll see in query examples throughout database vendor documentation. Multi-column SELECT lists are broken one column per line specifically because wide SELECT lists are the single most common place where a one-line query becomes genuinely unreadable — a ten-column SELECT crammed onto one line forces horizontal scrolling that a vertical list avoids entirely.
WHERE clauses with several AND/OR conditions get the same treatment: each condition drops to its own indented line, which makes the logical structure of a compound condition immediately visible instead of buried in a run-on sentence of comparisons.
Arb Digital handles the data and integration side of marketing sites and apps — from database design to reporting queries to API integrations — so your team isn't formatting SQL by hand at 11pm.
See Our Services All Free ToolsCommon Mistakes to Avoid
- Formatting SQL with regex find-and-replace. Naive approaches that just insert a newline before every
SELECTor after every comma break badly on subqueries, function calls, and string literals that happen to contain the word "from" or a comma. A tokenizer avoids this entirely. - Mixing keyword case within one query. Inconsistent casing (some keywords upper, some lower) is harder to scan than either convention applied consistently — pick one and format everything to match.
- Leaving a wide SELECT list on one line. Even a well-indented query loses most of its readability benefit if the column list itself still runs off the screen.
- Ignoring comments during cleanup. Comments often explain non-obvious business logic in a WHERE clause — a formatter should preserve them, not strip them, which this one does.
- Committing unformatted SQL to version control. A shared formatting convention, applied before every commit, keeps diffs small and reviews fast across a whole team.
Related Free Tools From Arb Digital
If you work with structured data day to day, pair this SQL formatter with our YAML to JSON converter and JSON to YAML converter for config files, or our CSS minifier when you're shipping the front end alongside your database changes. Browse everything in our free online tools hub.
Related tool: XML Formatter.
Frequently Asked Questions
Yes. The tokenizer and layout rules cover the core SQL clause structure shared across major dialects — SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, and LIMIT — along with quoted identifiers using double quotes or backticks. Dialect-specific extensions are generally passed through unchanged as plain identifiers or operators, so the query still formats sensibly even if a rare keyword isn't specifically recognized.
No. This SQL formatter only changes whitespace, line breaks, and keyword casing — it never reorders clauses, renames anything, or alters logic. The formatted query is functionally identical to what you pasted in; it's simply laid out for readability.
Yes, in a controlled way. The formatter tracks parenthesis depth so that commas and keywords inside a subquery or function call don't trigger the same top-level line breaks as the outer query — this prevents a formatted subquery from spilling into oddly broken lines.
No. All tokenizing and formatting happens locally in your browser using JavaScript. Nothing you paste — including queries with real table or column names — is sent to a server, logged, or stored.
Commas inside parentheses — function arguments like COUNT(a, b), an IN (1, 2, 3) list, or a subquery's own SELECT list — intentionally stay on the same line. Only commas that separate items in the outermost SELECT column list, at the query's top level, start a new line.
Yes — change the Keyword case option and click Format SQL again on the same input. The tool re-tokenizes and re-applies casing every time you run it, so switching styles takes one click.
