SQL Formatter
Beautify and format SQL instantly — clause-per-line indentation, aligned JOINs and WHERE conditions, nested subqueries indented by depth, and consistent keyword casing. Or minify a query down to one line. Pick 2/4/tab indent and uppercase keywords; string literals and -- / /* */ comments are preserved exactly. Everything runs in your browser; nothing is uploaded.
Formatted entirely in your browser — your SQL is never uploaded or sent anywhere, so it is safe for queries that reference real table, column or schema names. This is a formatter, not a validator or executor: it re-indents your SQL and never runs it, and string literals, quoted identifiers and -- / /* */ comments are preserved verbatim.
What this tool is
- A free, in-browser SQL formatter and beautifier — paste a query and get it cleanly indented, with major clauses on their own lines, in one click. No signup, nothing uploaded.
- Format or minify: pretty-print for readability, or collapse a query to a single compact line (whitespace outside strings and comments is removed).
- Control the output: 2-space, 4-space or tab indentation, uppercase keywords on or off, and each selected column on its own line.
- Built for real SQL: it indents subqueries by paren depth, lines up JOINs and WHERE conditions, and preserves string literals, quoted identifiers and -- and /* */ comments exactly — the word SELECT inside a string is never touched.
- Everything runs client-side, so it is safe to paste a query that references real table, column or schema names — your SQL stays on your device.
What a SQL formatter does
A SQL formatter (or SQL beautifier) rewrites the whitespace and casing of a query without changing what it does. Queries copied from logs, ORMs, string concatenation or other people's code arrive as one long cramped line; a formatter re-emits them with each major clause — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY — on its own line, nested subqueries indented, and boolean conditions lined up. The query runs identically; it is just far easier to read, review and put in version control.
Format vs. minify
Format expands a query for humans. Minify does the opposite: it collapses all the optional whitespace to produce the most compact single-line form, which is handy for embedding a query in a config value, a one-line log statement or a URL. Minifying here only touches whitespace that is outside string literals and comments, so the query stays equivalent — and because a -- line comment runs to the end of its line, the minifier keeps a newline after one so it cannot accidentally comment out the rest of your statement.
Strings and comments are never touched
The formatter tokenizes your SQL before it lays anything out, and it treats single-quoted strings, double-quoted and backtick identifiers, dollar-quoted blocks and both comment styles as opaque — they are copied through byte-for-byte. That means a string literal like 'orders FROM 2024' keeps its spacing and is never mistaken for the FROM keyword, and your comments survive exactly as written. If a query is malformed or uses syntax the tool doesn't recognise, it degrades to safe whitespace normalization rather than throwing away or corrupting your input.
Formatting as a review aid
- Over-broad statements stand out. A missing
WHEREon anUPDATE/DELETE, a blanketSELECT *, or a JOIN with no condition are obvious when the query is laid out clause-by-clause instead of buried in one line. - Injection points become visible. When a query is formatted, the places where strings are concatenated or interpolated — the classic source of SQL injection — are easy to spot, so a reviewer can flag input that should be passed as a parameter rather than glued into the SQL.
- Diffs stay meaningful. Consistent formatting means a change in a query shows up as a change in logic, not a reshuffle of whitespace — which keeps code review focused on what actually changed.
Good to know: this is a formatter, not a validator or an executor. It never connects to a database and never runs your query — it only re-indents the text, locally, in your browser. Formatting makes injection and over-broad queries easier to notice in review; it is not itself a defence. Parameterized queries (bind variables) remain the fix for SQL injection, and nothing here changes the behaviour or safety of a query it formats.
Frequently asked questions
What is a SQL formatter?
A SQL formatter (also called a SQL beautifier or pretty-printer) takes a query that is minified, cramped or inconsistently indented and re-emits it with clean, predictable layout: major clauses such as SELECT, FROM, WHERE, JOIN, GROUP BY and ORDER BY start on their own lines, subqueries are indented by their parenthesis depth, boolean conditions line up under WHERE, and keywords are cased consistently. The result is far easier to read, review and diff than a single long line. This tool formats in your browser with your choice of 2-space, 4-space or tab indentation, optional uppercase keywords, and the option to put each selected column on its own line — and it can also minify, collapsing a formatted query back down to one compact line.
Is my SQL sent to a server?
No. All formatting and minifying happens entirely in your browser using JavaScript — there is no network request, no upload and no logging of your query. That is deliberate: SQL often contains real table names, column names, schema details and sometimes literal values that reveal how your data is structured, which you should not paste into a random server-side tool. Because this runs locally, it is safe to format a query straight from your production codebase or a database console.
Does it validate or run my SQL?
No — this is a formatter, not a validator or an execution engine. It never connects to a database and never runs your query; it only re-indents and re-cases the text. It also does not guarantee your SQL is syntactically valid for a particular database. It is built to be robust rather than strict: it tokenizes your input (respecting strings and comments) and lays it out, and if a query is ambiguous or malformed it degrades gracefully to safe whitespace normalization instead of failing. If you need to check correctness, run the formatted query against your actual database or linter.
Why format SQL — does it help with security reviews?
Yes, indirectly but meaningfully. Formatted SQL is much easier to review, and review is where many problems are caught. When a query is laid out with one clause per line and conditions aligned, an over-broad statement (a missing WHERE on an UPDATE or DELETE, a SELECT * that exposes more columns than intended, a JOIN with no join condition) jumps out instead of hiding in a wall of text. It also makes string concatenation and interpolation points — the classic source of SQL injection — visible, so a reviewer can spot where untrusted input is being glued into a query rather than passed as a parameter. Formatting is not a substitute for parameterized queries or a scanner, but a readable query is a reviewable query.
Which SQL dialects does it support?
It is dialect-agnostic and works well with the common shapes of MySQL, PostgreSQL, SQL Server, SQLite, Oracle and standard ANSI SQL — SELECT/INSERT/UPDATE/DELETE, JOINs, subqueries, CTEs (WITH), set operations (UNION / INTERSECT / EXCEPT), window functions and typical DDL. It understands single-quoted strings (including doubled-quote and backslash escapes), double-quoted and backtick-quoted identifiers, dollar-quoted strings, and both -- line comments and /* */ block comments, all of which are preserved verbatim. Because it is a layout tool rather than a full parser, it will not reject dialect-specific syntax it does not recognise — it simply formats what it can and leaves the rest intact.