SQL Formatter

A free online SQL formatter that runs in your browser

This SQL formatter turns dense, hard-to-read queries into clean, properly indented SQL in a single click. Paste a query, choose your style, and read the beautified result instantly — there's nothing to install and no account to create. Every query is processed locally in your browser, so the SQL you paste is never uploaded, which matters when it contains real table names, schema details or sample data.

As a SQL beautifier and pretty printer it puts each clause on its own line, indents columns and conditions, and lines up your joins — the same readable layout you'd get from an IDE plugin, but available anywhere, on any device, including your phone.

Beautify or minify — across every major dialect

Switch between two modes. Beautify expands a query into a tidy multi-line layout; Minify collapses it back to a single line and strips comments, perfect for embedding a query in code or a config file. To minify SQL you just flip the mode and copy.

Unlike basic formatters, this one is dialect-aware. Choose MySQL, PostgreSQL, SQL Server (T-SQL), Oracle, SQLite, BigQuery, Snowflake or Standard SQL and it adapts to that engine — recognising MySQL backtick identifiers and # comments, or T-SQL bracketed identifiers like [Order Details] — so a postgresql formatter, a t-sql formatter and an oracle sql formatter all live in one place.

Keyword case, indentation and comma style — your way

Formatting style is personal, so this tool gives you the controls the popular formatters charge for. Set keyword case to UPPERCASE (the classic convention that makes SELECT and FROM pop), lowercase, Capitalized, or Keep as-is to preserve exactly what you typed.

Choose your SQL indentation width — 2 spaces, 4 spaces or a tab — and pick trailing or leading commas for the SELECT list. Subqueries are indented one level deeper automatically, and string literals and comments are always left untouched so nothing inside your query is corrupted.

Why format SQL?

Readable SQL is easier to debug, easier to review and produces cleaner diffs in version control. When every teammate formats the same way, a code review highlights real logic changes instead of whitespace noise. A consistent layout also makes it far quicker to spot a missing join condition or a misplaced parenthesis in a long query.

If you copied SQL out of a log, inherited a one-line ORM query, or want to tidy your work before committing, running it through a SQL query formatter takes a second and saves the next reader minutes.

How it compares to sqlformat.org, poorsql.com and IDE formatters

The two most linked free online SQL formatters are sqlformat.org and poorsql.com. Both upload your query to a server for processing, which matters if the SQL contains real table names, sensitive column names, or sample data rows. sqlformat.org has been around for years but dialect support is limited, there's no minify mode, and comma placement is fixed. poorsql.com — historically named the 'Poor Man's SQL Formatter' — is even more minimal: single indent style, no keyword-case toggle, no download.

Desktop formatters like Redgate SQL Prompt are polished but require installation and only work inside SQL Server Management Studio or Visual Studio. SQLFluff is excellent for CI pipelines but needs Python and a command line. Prettier can format SQL via a plugin but requires Node.js. This tool needs none of that: it runs instantly in any browser, works on mobile, processes everything locally, and adds configurable dialect support, minification, and download — filling the gap between 'paste to a basic web form' and 'set up a toolchain'.

Works for DDL, DML and everything in between

The formatter understands the whole language, not just SELECT statements. It cleans up DML (SELECT, INSERT, UPDATE, DELETE), lays out DDL column definitions in CREATE TABLE statements one per line, and handles CTEs (WITH …), window functions, UNIONs, CASE expressions and nested subqueries.

It's a pragmatic SQL pretty printer rather than a full query planner — it reformats your text without executing or validating it — so it's fast, private, and works the same whether your query is five lines or five hundred.

Private, instant and free — works on any device

There's nothing to sign up for and nothing to pay. Every format and minify happens in your browser using JavaScript, so your SQL never leaves your device, and it keeps working even offline once the page has loaded. Bookmark this SQL beautifier and reach for it any time you need to format, indent or minify a query.

The tool works on iPhone and Android just as well as desktop. Paste a query from a mobile chat or ticket, format it on the spot, and copy the result back — no app to install, no account to log into. It loads fast, responds instantly, and gets out of your way.

SQL dialects and why the same query looks different everywhere

ANSI SQL (standardized in 1986 and revised through SQL-92, SQL:1999, SQL:2003, SQL:2011, and SQL:2016) defines a portable core, but every database vendor adds proprietary extensions that diverge quickly in practice. Something as simple as joining two strings differs across engines: PostgreSQL, SQLite, and Oracle use the || operator, SQL Server uses +, and MySQL uses the CONCAT() function. Date functions are equally fragmented — NOW() in MySQL, GETDATE() in SQL Server, SYSDATE in Oracle, and CURRENT_TIMESTAMP in standard SQL all return the current time but are not interchangeable.

Auto-incrementing primary keys are another source of friction. PostgreSQL uses the SERIAL pseudo-type (or the newer GENERATED ALWAYS AS IDENTITY), MySQL uses AUTO_INCREMENT, SQL Server uses IDENTITY(1,1), and Oracle uses sequences with a trigger. Paging results is similarly dialect-specific: MySQL and PostgreSQL use LIMIT n OFFSET m, SQL Server uses TOP n or the newer FETCH FIRST n ROWS ONLY, and older Oracle relies on ROWNUM. A formatter that understands these dialects tokenizes your query against the right keyword set, so it never misidentifies a dialect-specific function as a generic identifier and formats your code correctly for the target engine.

Boolean literals expose the same split: standard SQL and PostgreSQL accept TRUE and FALSE; older MySQL and SQLite use 1 and 0; SQL Server has no BOOLEAN type at all and uses the BIT datatype instead. Window functions — introduced in SQL:2003 — are now widely supported across PostgreSQL, SQL Server, Oracle, and MySQL 8+, but the exact syntax for frame boundaries and the GROUPS mode still varies. Knowing which dialect you're targeting before you format prevents the formatter from mis-casing vendor keywords or breaking dialect-specific syntax that would otherwise confuse a generic parser.

How SQL parsers and formatters work under the hood

A SQL formatter is a specialised compiler front-end that stops just before code generation. The first step is lexing (tokenization): scanning the raw SQL string character by character and emitting a stream of typed tokens — keywords like SELECT and JOIN, identifiers (table and column names), string and numeric literals, operators, parentheses, and whitespace. Whitespace tokens are normally discarded by the lexer, but a formatter keeps them in a side channel because preserving comment positions requires knowing exactly where each comment sat relative to the code around it.

The second step is parsing: consuming the token stream and building an Abstract Syntax Tree (AST). A recursive-descent parser handles the nested structure of SQL naturally — a SELECT statement can contain a subquery in the FROM clause, which can itself contain a correlated subquery in its WHERE clause, and so on to arbitrary depth. The AST makes the structure explicit: the root node is a statement, its children are clauses, each clause's children are expressions, and each expression may have sub-expressions. CTEs (WITH blocks), CASE expressions, and set operations (UNION, INTERSECT) all appear as first-class nodes in the tree.

The final step is pretty-printing: traversing the AST and emitting formatted SQL. At each node the printer decides whether to emit inline (everything on one line) or expanded (each child on its own indented line), guided by line-length limits and clause-level rules. This is why regex-based formatters fail on complex SQL: a regular expression cannot match arbitrarily nested parentheses, cannot distinguish a keyword inside a string literal from a real keyword, and cannot track indentation depth through recursive structures. A proper AST-based formatter handles all of that — nested subqueries indent correctly, keywords inside 'string literals' are never uppercased, and multiline comments are re-attached to the correct statement node after reformatting.

CTEs, window functions, and modern SQL patterns

Common Table Expressions (CTEs), written with the WITH keyword, let you name intermediate result sets and reference them later in the same query, turning a deeply nested mess of subqueries into a readable sequence of named steps. A query that derives a filtered customer list, joins it to orders, and then aggregates by region becomes three clearly labelled blocks rather than three layers of brackets. Recursive CTEs extend this further: by adding a UNION ALL self-reference inside the CTE you can traverse hierarchical data — organisational charts, bill-of-materials trees, threaded comments — without procedural code. A good formatter indents the anchor and recursive members consistently, making the recursion boundary immediately visible.

Window functions (introduced in SQL:2003 and now supported by PostgreSQL, SQL Server, Oracle, MySQL 8+, SQLite 3.25+, BigQuery, and Snowflake) perform calculations across a set of rows related to the current row without collapsing the result into one row per group. The OVER (PARTITION BY dept ORDER BY salary DESC) clause defines the window; functions like ROW_NUMBER(), RANK(), DENSE_RANK(), LAG(), LEAD(), and SUM() operate within it. A running total, a percentile rank, a comparison of each sale to the previous month's sale — all achievable in a single pass without a self-join. Properly formatted, the PARTITION BY and ORDER BY sub-clauses appear on their own indented lines, making the window definition scannable at a glance.

Two more modern patterns worth knowing: LATERAL joins (PostgreSQL, MySQL 8+, BigQuery) allow a subquery in the FROM clause to reference columns from preceding table references — effectively a per-row subquery that replaces verbose correlated subqueries in the SELECT list. The FILTER clause on aggregates (SUM(salary) FILTER (WHERE dept = 'engineering'), supported in PostgreSQL, SQLite, and DuckDB) is a cleaner alternative to wrapping a CASE WHEN inside every aggregate. Both patterns produce more readable SQL when formatted with proper indentation, and a dialect-aware formatter recognises them as valid syntax rather than flagging them as parse errors.

SQL injection — the most dangerous SQL formatting mistake

SQL injection occurs when user-supplied input is concatenated directly into a SQL string rather than passed as a separate parameter. The classic example is a login check written as "SELECT * FROM users WHERE name = '" + username + "'". If an attacker types ' OR 1=1; DROP TABLE users; -- as the username, the resulting string becomes two statements: a SELECT that returns all rows (because 1=1 is always true) and a DROP that destroys the table. The double-dash comment syntax then silences whatever comes after. This is the joke behind xkcd #327 ("Bobby Tables"), and it has caused real data breaches at companies of every size.

The fix is parameterized queries (also called prepared statements): write WHERE name = ? (or $1 in PostgreSQL) and pass the user's value as a separate argument. The database driver sends the SQL structure and the parameter value to the server independently — the server compiles the query plan before it ever sees the value, so it is structurally impossible for the parameter to be interpreted as SQL syntax. ORMs and query builders use parameterization internally by default; the danger arises when developers bypass them with raw string concatenation for convenience or to build dynamic ORDER BY columns. Even column and table names used dynamically must be validated against an allowlist — they cannot be parameterized and so must never be taken raw from user input.

SQL injection has appeared in the OWASP Top 10 every year since the list began in 2003 and consistently ranks first or second among web application vulnerabilities. A secondary risk is the exposure of SQL in error messages: an unhandled database exception that leaks a stack trace to the browser tells an attacker your table names, column names, and database engine version — the reconnaissance step of any targeted injection attack. A well-formatted, well-structured query is easier to audit for injection risks, easier to refactor to use parameters, and easier for a code reviewer to spot where raw interpolation has crept in. Formatting your SQL is not a security control by itself, but readable SQL is auditable SQL.