Paste any SQL query and get a plain-English, clause-by-clause breakdown. Click any card to highlight the corresponding SQL in the editor.
A SQL SELECT query is built from a collection of clauses, each performing a distinct operation on the data. They execute in a specific logical order that is different from the order in which you write them.
This order matters when writing queries: you cannot reference a SELECT-level alias in a WHERE clause (because WHERE runs before SELECT), but you can reference it in an ORDER BY clause (because ORDER BY runs after SELECT).
| Clause | Purpose | Required |
|---|---|---|
SELECT | Specify which columns (or expressions) to return | Yes |
FROM | Specify the source table(s) | Usually |
JOIN | Combine rows from a second table based on a condition | No |
WHERE | Filter rows before aggregation | No |
GROUP BY | Aggregate rows that share a common value | No |
HAVING | Filter aggregated groups | No |
ORDER BY | Sort the result set | No |
LIMIT | Restrict number of rows returned | No |
WITH | Define named subqueries (CTEs) for reuse | No |
| Type | Returns |
|---|---|
INNER JOIN | Rows that match in both tables |
LEFT JOIN | All rows from the left table; NULLs for non-matching right rows |
RIGHT JOIN | All rows from the right table; NULLs for non-matching left rows |
FULL JOIN | All rows from both tables; NULLs where no match exists |
CROSS JOIN | Every combination of rows from both tables (Cartesian product) |
A common source of confusion is knowing when to use WHERE versus HAVING:
WHERE country = 'USA'.HAVING COUNT(*) > 5.You can combine both in the same query:
SELECT country, COUNT(*) AS users
FROM users
WHERE is_active = 1 -- filters rows first
GROUP BY country
HAVING COUNT(*) > 100 -- then filters groupsThe biggest value of this tool is not just translating SQL into English. It is helping you build a mental model for what each clause contributes to the final result.
Paste a real query, click through each clause, then compare the explanation order to the logical execution order.
Load a sample, inspect the clause cards, then rewrite the query manually in the playground from memory.
Useful when a query comes from an ORM, query builder, or dynamic filter layer and you want to inspect the final structure before checking performance or safety.
Plain-English clause cards are a starting point. These paths connect the explanation back to the specific article cluster behind that clause pattern.
Use these guides when the explainer shows a WITH clause and you need a stronger mental model for multi-step SQL.
This path fits when the clause cards are readable but the result grain or join logic still feels easy to misread.
Relevant when you are reading generated SQL and need the security and maintainability context behind the final text.
If the explainer helps you read the query but the concept still feels fuzzy, jump into one of these focused guides.
Useful when the explainer shows OVER, PARTITION BY, or ranking logic that feels opaque.
Helpful when your query starts with WITH and breaks into multiple named steps.
A strong follow-up when the FROM and JOIN section is still hard to reason about.
Useful when the explained query is assembled at runtime and you need to reason about the final SQL shape safely.
Relevant when query explanation is also part of a security review for user-controlled filters or sorting.