Paste EXPLAIN output from PostgreSQL or MySQL and see a visual query plan with cost estimates.
EXPLAIN prints a query plan as indented text, which is what you stare at when debugging a slow query. This tool turns that text into a tree diagram: each node is one plan step - a seq scan, an index scan, a join - labeled with startup cost, total cost, and estimated rows. Indentation becomes nesting, so a Bitmap Index Scan beneath a Bitmap Heap Scan renders as a child node. The common surprise: cost numbers are arbitrary planner units, not milliseconds, and unless you ran EXPLAIN ANALYZE, every value is an estimate derived from table statistics.
A concrete input and expected output from the current implementation.
Input
Bitmap Heap Scan on tenk1 (cost=5.07..229.20 rows=100 width=244)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=100 width=0)
Index Cond: (unique1 < 100) Expected output
A two-node tree. The root card reads "Bitmap Heap Scan on tenk1", cost 5.07..229.20, rows=100; its single child reads "Bitmap Index Scan on tenk1_unique1", cost 0.00..5.04, rows=100. The child carries Index Cond: (unique1 < 100); the parent shows Recheck Cond: (unique1 < 100). The parent's startup cost (5.07) sits just above the child's total cost (5.04).
PostgreSQL plans build bottom-up: the heap scan cannot emit a row until the index scan has produced its bitmap, so the parent's startup cost is the child's total cost plus a small amount (5.07 versus 5.04). The tool draws that dependency as the parent-child edge.
The pasted text is identified as PostgreSQL or MySQL: PostgreSQL plans are indented trees with cost=(startup..total), rows, and width annotations, while MySQL plans are flat tables with id, select_type, table, type, key, and rows columns. Per-node numbers are extracted, and the indentation depth of each PostgreSQL line becomes tree nesting.
Each parsed node becomes a card labeled with the operation and table name, showing total cost and estimated rows, and parent-child steps are joined by edges. Because every ancestor's cost includes its descendants' costs, the tree's shape makes the dominant work - the subtree holding most of the total plan cost - visible at a glance.
No. Cost is an arbitrary unit the planner uses to compare candidate plans, not a time prediction. Actual duration depends on hardware, caching, and concurrent load, so no visualizer converts cost to time. Use this tool to compare plans, and EXPLAIN ANALYZE for measured timings.
Only indirectly. The tool shows the plan that was chosen, not the alternatives that were rejected. Re-run EXPLAIN with planner switches disabled - enable_seqscan=off, enable_hashjoin=off - and paste those plans in too; comparing the trees is the standard way to expose what the planner was weighing.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Format, validate, and beautify JSON with syntax highlighting and error detection.
Encode text or files to Base64 and decode Base64 strings back to their original form.
Format and indent SQL queries for better readability across all major dialects.
Convert HTML markup into clean Markdown syntax with support for tables and lists.
Write Markdown and see the rendered HTML output in real time with live preview.
Visualize unified diffs and patch files with color-coded additions and deletions.