SQL Formatter — Format SQL Queries Online Free

Paste your SQL query, choose your formatting options, and get clean, indented SQL in seconds.

Reviewed by the ToolNestr Editorial Team — July 2026

Keyword Case Indent

Lines: 0 · Chars: 0

How SQL formatting works

SQL formatting rearranges your query by splitting it into tokens (keywords, identifiers, operators, strings, and parentheses), then reconstructing it with consistent line breaks and indentation. The formatter recognises SQL keywords and places each major clause on its own line, making the query structure immediately visible. Subqueries inside parentheses receive an additional level of indentation, creating a clear visual hierarchy that mirrors the logical nesting of your query.

The tool applies line breaks before keywords such as SELECT, FROM, WHERE, JOIN, ON, AND, OR, ORDER BY, GROUP BY, HAVING, and LIMIT. Each clause is indented relative to its nesting depth, with keywords aligned at the current level and column names indented further. Parentheses trigger an indent increase when opened and a decrease when closed, so subqueries and nested expressions remain properly nested. String literals and comments are preserved exactly as written, regardless of the keyword case setting.

Worked example

A single-line query reformatted with 2-space indentation and uppercase keywords.

Input: SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.total > 100 ORDER BY o.total DESC

Output: SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.total > 100 ORDER BY o.total DESC

The formatter transforms a single-line SQL query into an indented, readable multi-line statement

Supported SQL statements

The formatter handles all major SQL statement types used in modern database systems. Each statement is parsed for its structural keywords and formatted with appropriate line breaks and indentation. The tool recognises the following statement types and formats them according to their specific clause structure.

SELECT queries

SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, JOIN, ON, AND, OR, IN, EXISTS, BETWEEN, LIKE, IS NULL, AS, DISTINCT, UNION, INTERSECT, EXCEPT, WITH (CTEs), subqueries.

INSERT statements

INSERT INTO, VALUES, SELECT (subquery insert), ON DUPLICATE KEY UPDATE, RETURNING, INSERT with multiple row values each on their own line.

UPDATE statements

UPDATE, SET (each assignment on its own line with comma), FROM, WHERE, JOIN in UPDATE, RETURNING, ORDER BY, LIMIT.

DELETE statements

DELETE FROM, USING, WHERE, JOIN in DELETE, RETURNING, ORDER BY, LIMIT, TRUNCATE.

CREATE / ALTER / DROP

CREATE TABLE, CREATE INDEX, CREATE VIEW, ALTER TABLE (ADD, DROP, MODIFY columns), DROP TABLE, DROP INDEX, DROP VIEW, column definitions and constraints.

Additional SQL constructs

MERGE, REPLACE, CASE WHEN, window functions (OVER, PARTITION BY, ROW_NUMBER, RANK), CTEs (WITH), UNION, INTERSECT, EXCEPT, EXISTS, and correlated subqueries.

Keyword	Formatting Rule	Example Placement
SELECT	New line, indent columns	\nSELECT\n col1,\n col2
FROM	New line, same level as SELECT	\nFROM\n table
WHERE	New line, indent conditions	\nWHERE\n col > 1
JOIN / ON	New line before JOIN, ON after	\n JOIN t2 ON t1.id = t2.id
ORDER BY	New line, indent columns	\nORDER BY\n col DESC
GROUP BY	New line, indent columns	\nGROUP BY\n col
AND / OR	New line in WHERE/HAVING/ON	\n AND col = 2
SET	New line, indent assignments	\nSET\n col = 1,
VALUES	New line, indent row tuples	\nVALUES\n (1, 'a'),
( ... )	Increase / decrease indent	(\n subquery\n)

Use cases for SQL formatting

Reviewing team pull requests

Code reviews involving SQL changes are significantly faster when queries are consistently formatted. A well-indented query lets reviewers immediately see the query structure, spot missing joins, incorrect WHERE conditions, or misplaced GROUP BY clauses without having to mentally parse a single-line query. Formatting SQL before submitting a PR is a courtesy to your reviewers and reduces the back-and-forth of review comments about readability. Many teams include SQL formatting as part of their coding standards checklist, and running a query through this formatter before commit ensures compliance without requiring a database connection.

Debugging complex queries

When a query returns unexpected results or runs slowly, the first debugging step is understanding what the query actually does. Formatting reveals the logical structure: which tables are joined, what conditions filter the data, how aggregation is applied, and what ordering is used. A formatted query makes it easy to trace through the execution mentally or to explain the query to a colleague. Performance issues such as missing WHERE clauses, unintended Cartesian joins, or inefficient subqueries become obvious when the query is laid out clearly. Developers frequently paste an unreadable production query into the formatter as the first step in investigating a bug report.

Improving query readability in documentation

Technical documentation, tutorials, blog posts, and database schema documentation all benefit from cleanly formatted SQL examples. A formatted query is easier for readers to understand and follow, especially for beginners who are still learning SQL syntax. When writing documentation that includes SQL examples, run each query through the formatter first to ensure consistent presentation. This improves the professional quality of your documentation and reduces confusion for readers who may try to run the examples in their own database.

Preparing queries for sharing

When sharing SQL queries on Stack Overflow, in GitHub issues, in Slack messages, or in database forum posts, formatting makes your question clearer and increases the likelihood of getting helpful answers. A well-formatted query shows that you have put effort into presenting the problem clearly. It also helps respondents quickly identify syntax errors, logical mistakes, or optimisation opportunities. Format your SQL before copying it into a support ticket or community question to get better, faster responses from the community.

👩‍💻

Sarah Chen

Backend developer who formats SQL queries before committing them to the shared repository so team members can review changes quickly without parsing messy one-liners.

👨‍💼

Marcus Johnson

Data analyst who formats complex reporting queries to verify joins and aggregations before scheduling them in the ETL pipeline to run daily.

🧑‍🔧

Priya Patel

Database administrator who formats ad-hoc queries from developers to understand and optimise slow-running queries in production databases.

👩‍🎓

Alex Kowalski

Computer science student who formats SQL assignment queries to check syntax and better understand the relationship between clauses and subqueries.

Tips for writing readable SQL

Format before sharing

Always format your SQL before pasting it into a code review, documentation, or a support question. A formatted query communicates that you care about clarity and respect your reader's time. In team environments, establish a consistent formatting standard and use this tool to enforce it without requiring a database connection or IDE plugin.

Consistent style helps debugging

Adopting a consistent SQL style across your projects reduces cognitive load when switching between different queries or databases. When every query follows the same indentation and case conventions, you can focus on the logic rather than parsing the formatting. Debugging a formatted query is faster because the structure is immediately visible: you can trace the FROM clause, check the JOIN conditions, verify the WHERE filters, and confirm the ORDER BY columns without scrolling horizontally or mentally inserting line breaks.

Subqueries auto-indent

Subqueries are automatically indented one level deeper than their parent query, making it easy to distinguish outer query clauses from inner query clauses. Each opening parenthesis increases the indent level and each closing parenthesis decreases it, so deeply nested subqueries remain readable up to any practical nesting depth.

Use meaningful aliases

Table and column aliases should be meaningful and concise. Avoid single-letter aliases like a, b, c in queries with more than a few tables. Use descriptive aliases like ord for orders, cust for customers, or prod for products. Good aliases combined with clean formatting make queries self-documenting and reduce the need for inline comments explaining what each table represents.

Why SQL formatting matters

SQL formatting is not just about aesthetics — it directly impacts developer productivity, code review quality, and the maintainability of database code. In professional software engineering environments, SQL queries can span hundreds of lines with multiple joins, subqueries, CTEs, and complex WHERE conditions. Without consistent formatting, these queries become difficult to read, error-prone to modify, and time-consuming to review. A formatted query reveals its logical structure at a glance, allowing developers to understand what data is being requested and how it is being transformed without reading every token.

Code reviews benefit immensely from formatted SQL. When a pull request contains SQL changes, reviewers need to verify that the query logic is correct, that joins are properly conditioned, that aggregations make sense, and that the query will perform efficiently. An unformatted query forces the reviewer to spend mental energy on parsing the text itself rather than evaluating the logic. Formatting eliminates this overhead, making reviews faster, more thorough, and less frustrating. Teams that adopt SQL formatting standards report fewer review cycles per PR and higher confidence in SQL-related changes.

Query debugging and troubleshooting are another area where formatting pays dividends. When a production incident involves a slow or incorrect query, the first thing an engineer does is look at the query text. A formatted query allows the engineer to quickly identify which tables are involved, what filters are applied, and what sorting or aggregation is happening. This rapid comprehension can shave minutes off the mean time to resolution (MTTR) for database-related incidents. In high-traffic production environments where every minute of downtime costs significant revenue, these minutes add up quickly.

SQL formatting also plays a role in knowledge sharing and team onboarding. New team members who are learning the database schema benefit from seeing well-formatted example queries that clearly show how tables relate to each other and how data flows through the query. Consistent formatting reduces the learning curve for new hires and helps them become productive contributors more quickly. When all queries in a codebase follow the same formatting conventions, the codebase as a whole is more approachable and easier to maintain over time.

How the SQL formatter handles different SQL constructs

The formatter processes SQL by tokenising the input string and rebuilding it with formatting rules applied at the token level. Comments (both single-line -- and multi-line /* */) are preserved verbatim without reformatting. String literals wrapped in single quotes, double quotes, or backticks are treated as atomic tokens and left unchanged. Numeric literals, operators, and punctuation are handled according to their context within the query structure.

Parentheses are tracked with a nesting stack. Each opening parenthesis increases the current indent level, and each closing parenthesis decreases it. The opening parenthesis is placed at the end of the current line, and the content inside is indented by one additional level. This ensures that subqueries, inline views, and expression groupings are visually distinct. Commas in SELECT lists and SET clauses trigger a line break so each column or assignment appears on its own line. Keywords such as AND and OR are placed at the start of a new line within WHERE, HAVING, and ON clauses, making the logical chain of conditions easy to follow.

The keyword case setting is applied after the formatting structure is determined. Uppercase mode converts all recognised SQL keywords to uppercase, lowercase mode converts them to lowercase, and capitalize mode capitalises the first letter of each keyword. Identifiers, aliases, string literals, and comments are never modified by the case setting, preserving the original casing of table names, column names, and user-supplied text. This means you can use the formatter to standardise keyword casing across a team without worrying about accidentally changing the meaning of database identifiers.

SQL formatter implementation approach

Unlike JSON or XML formatters that rely on a structured parser, an SQL formatter works at the lexical level by recognising keywords and structural tokens. The implementation first splits the input SQL into individual tokens, where each token is either a keyword, an identifier, a string literal, a number, an operator, a parenthesis, or a comment. Tokens are identified by scanning the input character by character, grouping characters into tokens based on SQL lexical rules.

Once tokenised, the formatter walks through the token list and builds the formatted output line by line. When it encounters a major keyword (SELECT, FROM, WHERE, etc.), it emits a newline and the current indent level before the keyword. When it encounters a comma at a clause boundary, it emits a newline with an extra indent. Parentheses trigger indent level changes and appropriate line breaks. The result is a query that mirrors the structural decisions a human would make when formatting SQL by hand, but applied consistently and without errors.

The formatter handles edge cases such as leading/trailing whitespace, multiple consecutive spaces, empty input, and semicolons. It does not attempt to validate the SQL — it will format any text that looks like SQL, leaving validation to the database engine. This means you can format incomplete queries or queries with syntax errors during development, and the formatter will still produce readable output that helps you spot the mistake.

Security and privacy

This SQL formatter processes all data entirely within your browser. Your SQL queries are never sent to any server, stored in any database, or logged in any system. The formatting logic runs locally using JavaScript's string processing capabilities, ensuring that sensitive data such as customer information in queries, proprietary database schemas, or business-critical query logic never leaves your device.

Because all processing is local, there are no data retention policies, server logs, or third-party analytics to track your queries. The tool does not use cookies, tracking scripts, or external services in connection with its core functionality. You can confidently format queries containing confidential data, production database names, or internal business logic without risk of exposure or data leakage.

Frequently asked questions

What SQL dialects are supported?

Standard SQL with support for MySQL, PostgreSQL, SQLite, and BigQuery syntax.

Can I change keyword case?

Yes — toggle between UPPERCASE (SELECT), lowercase (select), or Capitalized (Select).