Readable SQL helps you review a query before running it in the database. Choose the dialect so the formatter interprets its syntax appropriately.

Open the SQL Formatter to follow the workflow. Processing runs in your browser; the tool does not upload the input for conversion.

A practical workflow

  1. Paste the SQL source. Use a query rather than a complete application file.
  2. Choose dialect, case and indentation. Match the dialect to the database you use.
  3. Format and review the query. Inspect the formatted clauses and correct any parser errors.
  4. Download the source. Save formatted.sql and test it in the actual project before execution.

Try a concrete example

The following demonstration input is also available in the workspace. Replace it with your own data after checking the expected behaviour.

select name,email from customers where active=1 order by name;

With the default settings, the result is:

SELECT
  name,
  email
FROM
  customers
WHERE
  active = 1
ORDER BY
  name;

Choose the database language first

MySQL, PostgreSQL, SQL Server and other databases have different extensions. A dialect setting helps the formatter recognise those forms. If a statement is unsupported, reduce it to the relevant query or review the library documentation instead of guessing that its output is authoritative.

Use case and indentation consistently

Keyword case and indentation affect presentation, not the execution plan. Format a query to make clauses and expressions easier to compare. Keep a copy of the original and use a difference view to review what changed before putting the result into a project.

Formatting does not optimise the query

The tool does not connect to your database, inspect indexes or execute SQL. It cannot decide whether the query is efficient or safe for production. Use parameterised queries and database-specific testing in the actual application. Stored procedures and some extensions may fall outside the formatter support.

If the result needs attention

Formatting is not query execution, optimisation or proof of correctness. Some stored procedures and dialect extensions are unsupported.

Read the exact error before changing the input. Keep a copy of the original, reduce the sample when investigating a large file, and use the destination application to verify that the result has the meaning you intended. The tool processes the supplied data; it cannot infer an unstated application schema or project requirement.

Use the Text Diff Checker to compare a saved result with the original. Keep transformation and application testing as separate steps so presentation changes are not mistaken for verified behaviour.

Sources and further reading

Turn the next step into a project

Need help with a brand identity, business website or launch assets? Explore SOPIDOTECH services and client projects, or discuss your brief.

Keep learning