Format SQL with the right dialect
Format SQL locally, preserve quoted values and understand why readable SQL still needs execution-plan and transaction checks.
Try the calculation or tool
Choose the database before formatting
SQL dialects disagree on identifier quotes, parameters, casts and procedural syntax. Select the language that matches your query rather than assuming all SQL is interchangeable. PostgreSQL, MySQL, SQLite and Transact-SQL have different conventions. This formatter changes layout using the sql-formatter library; it does not connect to a database, execute SQL or prove that a query is valid.
Keep a source copy
Paste a working copy of the statement, select its dialect and format it. Review the diff, especially string literals, quoted identifiers, comments and parameter placeholders. For example, the spaces inside a string value must remain part of that value. If a formatter rejects a vendor extension, keep the original and consult the library’s supported syntax instead of deleting clauses to make the formatting pass.
Read the logic after the layout
Indentation can make joins and predicates easier to inspect, but cannot decide whether they express the intended relationship. Check each join condition, parentheses around mixed AND/OR conditions, and whether a WHERE clause accidentally turns a left join into an inner join. Confirm that aggregate filters belong in HAVING when appropriate. These checks require knowledge of the schema and expected results.
Test separately in the database
Use a safe development dataset, the application’s normal parameter binding, and an execution plan where supported. For a data-changing statement, review the affected rows and transaction behaviour. A successful format is not a successful query test, a security check or an optimization. The formatter below has a size limit to keep the browser responsive and reports unsupported syntax without changing the input.