Make a SQL query easier to inspect, while keeping formatting separate from correctness, performance and execution.
A long SQL query on one line is difficult to review. Formatting exposes the structure so you can see selected fields, joins and conditions. It is a reading aid; it does not prove the query is correct or safe to run.
Begin with a harmless example
SELECT title, starts_at FROM workshops WHERE published = 1 ORDER BY starts_at;Breaking this into clauses makes the selected columns, table, filter and order easier to identify. The meaning should remain the same.
Use the formatter on a copy
- Keep the original query unchanged.
- Open the SQL formatter.
- Paste a sample without private values or credentials.
- Inspect the formatted output.
- Compare it with the original before using it in your development workflow.
SQL dialects differ. A formatter may not understand every database-specific construct. If it changes or mishandles an unfamiliar expression, retain the original and use tooling that supports your database.
Review the actual logic separately
Ask whether the joins match the intended relationships, the filters select the intended rows and any aggregation uses the right grouping. Nice indentation does not answer those questions.
For a statement that changes data, formatting is not authorization to execute it. Review the affected scope and use your normal backup, transaction and testing process. The public tool's role is to help inspect text.
Keep sensitive values out of examples
Even a read-only query can reveal internal table names, customer details or business logic. Replace private values and use invented table names when you only need to investigate layout.
Try the formatter with the example above. If your API payload also needs attention, use the JSON troubleshooting guide. Create a r37dy account for the platform's link-management features when your project needs them.