NineClip Free Tools

SQL Formatter

Beautify a one-line SQL query — major clauses on their own lines, keywords capitalised, columns split out — right in your browser. A quick keyword tidier, not a SQL parser.

Developer Tools● Free No upload Instant

Loading SQL Formatter…

Your browser is preparing the tool. It runs 100% locally.

Quick Answer

Paste a cramped or one-line SQL statement and the tool lays it out: each major clause (SELECT, FROM, WHERE, JOIN, ORDER BY and so on) starts a new line, those keywords are capitalised, and each comma-separated column goes on its own indented line. It is a lightweight keyword tidier — it does not parse the SQL — so it is great for readability but has no awareness of dialects, subqueries or strings. It runs in your browser; nothing is uploaded.

What the SQL Formatter Does

This tool takes a SQL query that has been written or generated on a single line and reformats it into the conventional, readable shape: clauses stacked vertically, keywords in capitals, and a column list broken out one per line.

It is the quick way to make a long query legible — to review a statement copied from a log, an ORM, or a query builder without pasting it into a database client.

How It Works

The tool first collapses all runs of whitespace to single spaces. It then looks for a fixed list of SQL keywords — SELECT, FROM, WHERE, the JOIN family, GROUP BY, ORDER BY, HAVING, LIMIT and the main write statements — and starts a new line before each one, capitalising it as it goes. Finally, it puts each comma on its own line and indents the item that follows.

This is keyword matching, not parsing. The tool does not understand the query's structure, tables or expressions — it only recognises those specific words and the comma. That makes it fast and dependency-free, and it reads simple queries well, while complex ones need a proper formatter.

Processing pipeline

  1. Collapse whitespace. Reduce every run of spaces, tabs and newlines to a single space.
  2. Break before keywords. Start a new line before each keyword in the list, capitalising it.
  3. Split the comma list. Put each comma on its own line and indent the item after it.
  4. Trim and return. Tidy the leading and trailing whitespace and return the formatted query.

How it reformats

1 · collapse all whitespace to single spaces 2 · start a new line before each listed keyword, capitalised (SELECT, FROM, WHERE, JOIN family, GROUP BY, ORDER BY, HAVING, LIMIT, …) 3 · put each comma on its own line, indented two spaces
Worked example
Before: select id,name,email from users where active=1 order by name After: SELECT id, name, email FROM users WHERE active=1 ORDER BY name

Only the keywords in the list are capitalised and broken onto new lines; other text is left as you wrote it. Every comma is split, including commas inside a function call or a VALUES list.

Privacy

Your query never leaves your device. It is reformatted in your browser with no network request, so nothing is uploaded.

Because the work is local, you can safely tidy queries that mention real table names or internal schema without them being stored or sent anywhere.

Nothing persists between sessions — close the tab and the input and output are gone.

Standards & references

  • SQL (ISO/IEC 9075) — The standard for the SQL language. Keywords are case-insensitive, so capitalising them is a readability convention, not a requirement. The tool capitalises only the keywords it knows.
  • Keyword casing convention — Writing SQL keywords in uppercase and identifiers in lower or mixed case is a widely used style that makes the shape of a query easier to scan. This tool follows it for its keyword list.
  • Parser-based formatters — Tools that parse SQL into a syntax tree (such as sqlformat or a Prettier SQL plugin) understand dialects, subqueries and strings, and reprint reliably. This tool is a lighter keyword tidier.

Accuracy & Limitations

It reads simple queries cleanly, but it is a keyword tidier, not a parser. It does not understand the query, so it cannot validate it, align subqueries, or know which dialect you are using — it only reacts to a fixed set of words and the comma.

The keyword list is short. Common words such as UNION, AS, LIKE, BETWEEN, IN, and CASE or WHEN are not in it, so they are neither capitalised nor broken onto a new line. Complex queries keep parts of their original layout.

Every comma is split onto a new line, including commas inside a function call, a VALUES list or a CAST. That can over-split a query, putting function arguments on separate lines where you would rather keep them together.

It matches keywords as whole words wherever they appear, so a keyword used inside a string literal — for example the word order within quotes — can be wrongly capitalised and broken. A parser would know it was inside a string and leave it alone.

Real-World Use Cases

Reading a logged query

Lay out a one-line statement from a log or an ORM.

Reviewing a query

Stack the clauses to scan a statement quickly.

Tidying before sharing

Format a query for a pull request or a message.

Teaching and notes

Present SQL clearly in documentation.

When to use it — and when not to

Good for

  • Reading a one-line or cramped query
  • Stacking clauses and capitalising keywords
  • A quick tidy of a simple SELECT
  • A fast, no-install format

Not the best choice for

  • Complex queries with subqueries or CTEs
  • Statements that rely on UNION, CASE, LIKE and the like
  • Queries with keywords inside string literals
  • Dialect-aware or validating formatting

For complex, dialect-aware formatting that handles subqueries, strings and CTEs, use a parser-based tool (such as sqlformat or a SQL plugin in your editor or database client). This tool is for a fast in-browser tidy of a simple query.

Frequently Asked Questions

Does it capitalise all SQL keywords?
Only the ones in its list — SELECT, FROM, WHERE, the JOIN family, GROUP BY, ORDER BY, HAVING, LIMIT and the main write statements. Words like UNION, AS, LIKE and CASE are not included, so they are left as written.
Why did it put every column on a separate line?
It breaks the line after every comma. That neatly separates a SELECT list, but it also splits commas inside function calls and VALUES lists, which can over-split a query. You may want to rejoin those by hand.
Is it a real SQL parser?
No. It matches a fixed set of keywords and the comma using regular expressions. It does not understand the query's structure, tables or dialect, which is why it is fast but limited.
Does it validate my SQL?
No. It only reformats the text. It cannot tell you whether the query is correct or will run — for that, test it against your database or a parser-based linter.
Will it handle subqueries and CTEs?
Not as nested blocks. It treats keywords wherever they appear without understanding nesting, so a subquery is broken onto lines but not indented as its own block. Complex queries need a parser-based formatter.
What if a keyword appears inside a string?
It can be wrongly capitalised and broken. The tool matches whole words anywhere in the text, so a word like order inside quotes is treated as the keyword. A parser would know it was inside a string and leave it alone.
Does it change my table or column names?
No. Only the listed keywords are capitalised. Identifiers such as table and column names are left exactly as you wrote them.
Is my query uploaded anywhere?
No. It is formatted entirely in your browser. Nothing is sent to a server, so queries that mention real schema stay on your device.
How much does it indent?
Two spaces for each item after a comma. Clause keywords start at the left margin on their own lines.
Does it support all SQL dialects?
It is dialect-agnostic in that it only matches common keywords, but it has no special knowledge of any dialect's extra keywords or syntax. Dialect-specific statements may not be formatted fully.
Why did a second run change the output?
It is not guaranteed idempotent, because it reacts to the current text rather than rebuilding from a parsed query. A parser-based formatter gives the same result every time.
Should I use this or a parser-based formatter?
For a quick read of a simple query, this is convenient. For complex queries, validation, or dialect-aware output, a parser-based SQL formatter is the better choice.

References

Breaks lines before a fixed list of SQL keywords and after commas, and uppercases those keywords; honest that it is a pattern tidier, not a parser, so it has no dialect or subquery awareness.

PopularHot

JSON Formatter

JSON Formatter for developers — instant, offline-style and privacy-safe.

DeveloperOpen Tool
Popular

JSON Validator

JSON Validator for developers — instant, offline-style and privacy-safe.

DeveloperOpen Tool
Popular

Base64 Encoder

Base64 Encoder for developers — instant, offline-style and privacy-safe.

DeveloperOpen Tool
Popular

Hash Generator

Fast, free Hash Generator that runs entirely client-side in your browser.

DeveloperOpen Tool
Popular

UUID Generator

Fast, free UUID Generator that runs entirely client-side in your browser.

DeveloperOpen Tool
Trending

CSS Minifier

Fast, free CSS Minifier that runs entirely client-side in your browser.

DeveloperOpen Tool

Ready to try the SQL Formatter?

It is free, private and runs entirely in your browser — no sign-up, no uploads, no limits.

Use the tool now Explore Developer Tools