SQL Query Explainer

What does this SQL query explainer do?

Paste any SQL SELECT, INSERT, UPDATE, DELETE, or CREATE TABLE statement and get a plain-English breakdown of every clause — no account, no upload, and no data ever leaves your browser. It's built for students learning SQL, developers reviewing a teammate's query, and anyone who wants a fast sanity check before running something against a real database.

Why SQL execution order matters

SQL reads top to bottom, but it doesn't run top to bottom. A database engine evaluates FROM and JOIN first, then WHERE, then GROUP BY, then HAVING, then finally the columns in your SELECT list, followed by ORDER BY and LIMIT. That's why a column alias defined in SELECT can't be used in WHERE, and why HAVING — not WHERE — is the clause for filtering on an aggregate like COUNT(*). This tool lays that order out explicitly for whatever query you paste in.

Common mistakes it catches

Beyond explaining clauses, it flags patterns that often cause bugs or unexpected results: SELECT * in production code, an UPDATE or DELETE with no WHERE clause, ambiguous unqualified column names across joined tables, old-style comma joins, and mixing aggregate and non-aggregate columns without a GROUP BY.

Frequently asked questions

Does this tool run my query against a real database?

No. It only reads and analyzes the text of your query — nothing is executed, and no database connection is required or possible. Your query never leaves your browser.

Which SQL dialects does it support?

It's built around standard ANSI SQL clauses (SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, and more) that work the same way across MySQL, PostgreSQL, SQLite, and SQL Server. Highly dialect-specific syntax may not be recognized.

Why is HAVING different from WHERE?

WHERE filters individual rows before any grouping happens. HAVING filters groups after GROUP BY has already combined rows — which is why only HAVING can reference aggregate functions like SUM() or COUNT().