Developer Tools

Format SQL for the right dialect and review the result

A PostgreSQL formatting example, dialect selection tips and a practical review checklist. See why readable SQL does not prove validity or performance.

By Your Tech Tool · Published October 19, 2026 · 5 min read

How the examples are checked

Separate presentation from query behavior

A formatted query is easier to inspect because clauses, columns and nested expressions have a consistent layout. Formatting does not connect to the database, confirm that a table exists or measure an execution plan. The SQL Formatter changes whitespace and keyword presentation using the selected language; it is not a query optimizer or a translator between database systems.

Use a copy of the query while reviewing it. Remove private values if they are unnecessary for the task, and keep the original so you can compare the result. This page's formatter processes the input locally and never runs it.

A PostgreSQL example with a string literal

Select PostgreSQL as the dialect, UPPERCASE for keywords and 2 spaces for indentation.
Paste the input below and select Format SQL.
Compare the output, especially the selected columns, condition, quoted city name and sorting clause.

Input

select id, name from customers where city = 'Montréal' order by name;

Expected formatted SQL

SELECT
  id,
  name
FROM
  customers
WHERE
  city = 'Montréal'
ORDER BY
  name;

The keyword setting changes select to SELECT. It does not convert 'Montréal' to uppercase. The condition still refers to the same city string. There are no results to display because no database connection is made.

Match the language before fixing a parse error

Choose the language used by the source database or application's query generator. PostgreSQL, MySQL, SQLite and SQL Server share many basic clauses but differ in quoting, operators, placeholders and vendor extensions. The tool offers twelve dialect choices. Its formatter library describes dialect selection and supported options.

Syntax clues to investigate, not automatic dialect detection
Query feature	What to check
Backtick-quoted identifiers	Check whether the query came from MySQL or another dialect that supports that notation.
`created_at::date`	Check whether PostgreSQL-style casts are expected by the source system.
`[Customer Name]`	Check whether bracket quoting belongs to the selected SQL Server or compatible dialect.
A procedure body with a custom delimiter	Check the formatter's limits; use the database's own development tools when unsupported.

These clues are not unique proofs of a database type. Selecting a different dialect does not rewrite identifiers, data types or functions into equivalents for another engine. Database migration needs a separate review.

Review before using the formatted statement

Compare strings and comments, especially when a query includes generated syntax or unusual quoting.
Confirm that all intended WHERE, join and grouping conditions are present. A neat layout does not make a broad update safe.
Keep the indentation and keyword case your team can maintain; these settings do not make a query faster.
Validate against the intended database and schema using a suitable test environment and authorization.
Investigate performance with database-specific plan and measurement tools using representative data.

If formatting fails, start with the selected dialect, unclosed quotes or comments and text copied from logs. Reduce a large failing input to a complete statement that demonstrates the problem. The browser tool caps input at 200,000 characters and 80 levels of parentheses; those resource limits are not SQL language limits.