SQL Formatter

An SQL formatter takes a query that has been written on one long line, copied out of a log or generated by an application, and lays it out so each clause, column and condition is easy to follow. Our free SQL Formatter uses the open-source sql-formatter library and supports MySQL and MariaDB, PostgreSQL, SQL Server (T-SQL), SQLite and standard SQL. Choose upper, lower or preserved keyword case, indent with two or four spaces or tabs, format several statements at once, then copy or download the result. It only formats: it does not connect to a database or run anything, and your queries stay in your browser.

How to use the SQL formatter

1. 1 Paste your SQLDrop in a single query or several statements separated by semicolons. Queries from logs, ORMs, reports and stored procedures all work.
2. 2 Choose the dialectPick MySQL/MariaDB, PostgreSQL, SQL Server, SQLite or standard SQL so identifiers, operators and keywords specific to that database are recognised correctly.
3. 3 Set keyword caseChoose uppercase keywords for the traditional look, lowercase if your team prefers it, or preserve to leave keywords exactly as they were typed.
4. 4 Pick the indentationUse two spaces, four spaces or tabs to match the style used in your codebase, migrations or reporting tool.
5. 5 Format, then copy or downloadRun the formatter, review the layout, then copy it to your clipboard or download it as a .sql file.

Why formatting SQL matters

SQL is often written in a hurry and read many times afterwards. A query that joins four tables, filters on several conditions and groups the results can easily run to hundreds of characters. On a single line it is nearly impossible to see which condition belongs to which join, whether a bracket has been closed, or which columns are actually selected. Laid out properly, the same query reads almost like a sentence.

Good formatting puts each major clause, such as SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY and LIMIT, at the start of its own line, with the columns, tables and conditions that belong to it indented underneath. Nested subqueries and common table expressions are indented a further level, so the structure is visible at a glance. Readable queries are quicker to debug, easier to hand over to a colleague and far less likely to hide a mistake such as a missing join condition that quietly multiplies your rows.

Queries generated by frameworks and ORMs are a common case. Laravel, Django, Entity Framework and similar tools log the SQL they send to the database, usually as one compressed line. Formatting that output is often the fastest way to understand why a page is slow or why a report returns the wrong figures.

Formatting for code review and shared projects

When SQL lives in a repository, in migrations, views, stored procedures or reporting queries, consistent formatting pays for itself in code review. If everyone formats the same way, a diff shows the real change, such as an added condition or a new column, rather than a jumble of moved line breaks. Reviewers can then concentrate on whether the logic is right and whether the query will perform well.

Formatting also helps when SQL is shared outside the development team. Analysts, finance staff and managers increasingly read queries behind dashboards and reports in tools such as Power BI, Looker Studio or Metabase. A clearly laid-out query, with one column per line and meaningful aliases, is much easier for a non-specialist to check against what the report claims to show.

For projects with a lot of SQL, consider adding a formatter or linter to your editor or build process so the style is applied automatically. Our tool is handy for quick jobs, for queries you meet outside a project, and for agreeing on a style before you automate it.

Common SQL style conventions

There is no single official SQL style, and teams argue about the details. These are the conventions you will see most often, and the formatter options let you follow whichever ones your team has chosen.

• Uppercase keywords: writing SELECT, FROM and WHERE in capitals makes the structure stand out from table and column names. Many teams now prefer lowercase for a calmer look; either works if it is consistent.
• One column per line: listing each selected column on its own line makes it easy to add, remove or comment out a column and keeps diffs small.
• Trailing commas: the comma goes at the end of each line, as in normal writing. This is the most common style and the default in most formatters.
• Leading commas: the comma starts the next line instead. Some analysts like it because it is easy to comment out the last column without breaking the query, and a missing comma is easier to spot.
• Meaningful aliases: short but clear aliases such as c for customers and o for orders are easier to read than t1 and t2, especially in long joins.
• Explicit joins: writing INNER JOIN or LEFT JOIN with an ON clause is clearer and safer than listing tables separated by commas and joining them in the WHERE clause.

Choosing the right SQL dialect

SQL is a standard, but every database adds its own features and quirks, and the formatter needs to know which one you are using to read your query correctly. Picking the right dialect makes sure quoted names, operators and special keywords are recognised rather than mangled.

Quoting identifiers is the most visible difference. MySQL and MariaDB wrap table and column names in backticks. PostgreSQL, SQLite and standard SQL use double quotes, and in PostgreSQL a quoted name keeps its exact case. SQL Server uses square brackets, though it also accepts double quotes in its default settings. Strings, by contrast, use single quotes in all of them.

Limiting rows is another. MySQL, MariaDB, PostgreSQL and SQLite use LIMIT at the end of a query, often with OFFSET. SQL Server uses TOP straight after SELECT, or OFFSET and FETCH NEXT after an ORDER BY, which is also the form the SQL standard describes. Other differences include PostgreSQL's double-colon type casts and RETURNING clause, SQL Server's variables beginning with an at sign and its GO batch separator, and MySQL's use of the hash character for comments. If you are not sure, choose the database the query will actually run on, or standard SQL as a sensible fallback.

What the formatter does not do

The tool rearranges whitespace, line breaks and, if you ask it to, the case of keywords. It does not connect to any database, run your query, check that tables or columns exist, or tell you whether the results will be correct. A query can be beautifully formatted and still fail because of a typo in a column name or return the wrong rows because of a missing condition.

It also does not validate syntax in the way a database would. The formatter will do its best with incomplete or unusual SQL, and if a query contains a serious error the layout may look odd, which is itself a useful clue. To be certain a query works, run it against a development or test database, and use the EXPLAIN feature of your database to check how it will be executed before running anything expensive on live data.

Keeping your queries and data safe

Formatting runs entirely in JavaScript in your browser using the sql-formatter library. Your SQL is not sent to our server, stored or logged. That makes the tool suitable for queries that reveal table structures, business logic or internal reporting.

Even so, take care with what you paste into any website. Never include production database passwords, connection strings or API keys, which sometimes appear in scripts alongside the SQL. Be cautious with queries that contain real customer data in literal values, such as names, email addresses or account numbers; replace them with placeholders before sharing a formatted query with anyone else. Under UK GDPR, personal data should only be copied to places where it genuinely needs to be.

Nothing is saved between visits, so copy or download your formatted SQL before you close or refresh the page.

Examples you can copy

Before:
select c.name, count(o.id) as orders from customers c left join orders o on o.customer_id = c.id where c.city = 'Leeds' group by c.name order by orders desc limit 10;

After:
SELECT
  c.name,
  COUNT(o.id) AS orders
FROM
  customers c
  LEFT JOIN orders o ON o.customer_id = c.id
WHERE
  c.city = 'Leeds'
GROUP BY
  c.name
ORDER BY
  orders DESC
LIMIT
  10;

MySQL / MariaDB:
SELECT `name` FROM `customers` ORDER BY `name` LIMIT 5;

PostgreSQL / SQLite:
SELECT "name" FROM "customers" ORDER BY "name" LIMIT 5;

SQL Server:
SELECT TOP 5 [name] FROM [customers] ORDER BY [name];

Trailing:
SELECT
  id,
  name,
  postcode
FROM customers;

Leading:
SELECT
  id
  , name
  , postcode
FROM customers;

Common mistakes to avoid

Frequently asked questions