SQL Formatter & Beautifier

This formatter supports Standard SQL and the four most common database dialects. MySQL: backtick identifiers (`table`), LIMIT clause, AUTO_INCREMENT. PostgreSQL: double-quote identifiers ("table"), RETURNING clause, ILIKE, window functions. SQLite: minimal syntax, PRAGMA statements. SQL Server (T-SQL): square bracket identifiers ([table]), TOP instead of LIMIT, GO batch separator. The dialect selector adjusts keyword recognition and formatting hints, but the core beautification works on any SQL regardless of dialect.

SQL keywords (SELECT, FROM, WHERE, JOIN, etc.) can be written in any case — SQL is case-insensitive for keywords. The convention depends on your team's style guide: UPPERCASE is the traditional convention (most SQL books and DBA tools use it), making keywords visually distinct from table and column names. lowercase is increasingly popular in modern teams, especially those who use ORMs. Preserve keeps whatever casing you typed. Google's SQL style guide recommends uppercase; GitLab's recommends lowercase. The most important thing is consistency within your codebase.

Trailing commas (the default) put commas at the end of each line: col1, / col2, / col3. Leading commas put them at the start: col1 / , col2 / , col3. Leading commas make it easier to comment out a column without breaking the syntax (you never leave a trailing comma on the last line). They are common in some database teams, particularly those working with older SQL Server or Oracle codebases. Trailing commas are more standard and what most SQL formatters default to. Both are valid SQL.

SQL injection is an attack where malicious input manipulates your SQL query. Example: if you build SELECT * FROM users WHERE name = '${input}' and the user enters '; DROP TABLE users; --, your database executes three statements. Formatting helps by making query structure visible — poorly structured queries are easier to spot when formatted. The real prevention is parameterized queries (prepared statements): SELECT * FROM users WHERE name = ? with the value passed separately. Never concatenate user input into SQL strings. Use parameterized queries in every language: cursor.execute("SELECT * FROM users WHERE name = %s", (name,)) in Python, db.prepare("SELECT...") in Node.js.

SQL databases (MySQL, PostgreSQL, SQLite, SQL Server, Oracle) store data in structured tables with rows and columns, enforce schemas, support ACID transactions, and use the Structured Query Language. They excel at complex queries with joins across multiple tables. NoSQL databases (MongoDB, Redis, Cassandra, DynamoDB) store data as documents, key-value pairs, graphs, or wide columns. They sacrifice some query flexibility for horizontal scalability and schema flexibility. When to use SQL: structured data with clear relationships, need for complex queries, transactional integrity required (banking, e-commerce). When to use NoSQL: unstructured or rapidly changing data, massive scale, simple access patterns. Many modern applications use both.

Window functions perform calculations across a set of rows related to the current row, without collapsing them into a group (unlike GROUP BY). Syntax: function() OVER (PARTITION BY col ORDER BY col ROWS BETWEEN ...). Common window functions: ROW_NUMBER(), RANK(), DENSE_RANK(), LAG(), LEAD(), SUM() OVER(), AVG() OVER(). They are supported in PostgreSQL, SQL Server, Oracle, MySQL 8+, and SQLite 3.25+. When formatting window functions, the OVER clause and PARTITION BY/ORDER BY sub-clauses are indented for readability. Use the Highlight view to see the structure clearly.

WHERE filters rows before grouping — it operates on individual row values. HAVING filters groups after GROUP BY — it operates on aggregate values. Example: SELECT department, COUNT(*) as count FROM employees WHERE salary > 50000 GROUP BY department HAVING COUNT(*) > 5. Here WHERE removes individual employees with salary under 50K, then GROUP BY groups the remaining employees by department, and HAVING keeps only departments with more than 5 qualifying employees. You cannot use aggregate functions in WHERE; you must use HAVING for that. WHERE executes first and is more efficient as it reduces the data before grouping.

INNER JOIN: returns only rows where the join condition matches in both tables. Most common join type. LEFT JOIN: returns all rows from the left table, with matched rows from the right; unmatched right rows are NULL. Use when the left table is the "primary" entity. RIGHT JOIN: opposite of LEFT JOIN; rarely used (you can rewrite as LEFT JOIN). FULL OUTER JOIN: returns all rows from both tables; unmatched rows are NULL on the missing side. CROSS JOIN: returns every combination (cartesian product) of both tables; use with care on large tables. SELF JOIN: joins a table to itself, useful for hierarchies and adjacency lists. Most queries use INNER JOIN and LEFT JOIN. RIGHT JOIN and FULL OUTER JOIN are less common.

Yes, completely. All formatting happens in your browser using JavaScript. No SQL is sent to any server. This tool works offline once the page is loaded. We have no logs of what you paste. This makes it safe to paste queries containing sensitive column names, internal table structures, business logic, or even queries with embedded filter values. The only network request this page makes after load is for Google AdSense, which has no access to the content of the textarea. For extra caution, you can disconnect from the internet after the page loads and the tool will continue to work normally.

A CTE is a named temporary result set defined with WITH that you can reference in the main query. Syntax: WITH cte_name AS (SELECT ...) SELECT * FROM cte_name. CTEs improve readability by breaking complex queries into named, logical steps. Recursive CTEs (WITH RECURSIVE) can traverse hierarchical data like organizational charts or bill-of-materials. Multiple CTEs are separated by commas: WITH cte1 AS (...), cte2 AS (...) SELECT .... The formatter indents the CTE body and aligns the main query below it. CTEs are supported in PostgreSQL, SQL Server, Oracle, MySQL 8+, and SQLite 3.8.3+. They are not the same as views — CTEs exist only for the duration of the query.