Official boundary for weighted entries and rolls
Microsoft's current Bedrock creator tutorial defines loot tables through pools, entries, weights, rolls, functions, conditions, and referenced tables. Its simple example shows that entries with equal default weight are equally selectable and that a larger weight makes one entry proportionally more likely. It also shows that a pool can roll multiple times.
Microsoft: Creating a Loot Table
Mojang: Bedrock sample loot tables
What the weighted mode calculates
For a tracked entry weight w and total currently eligible weight W, the selection chance on one roll is w/W. With r fixed rolls that independently sample the same eligible pool with replacement, the chance of at least one selection in a complete table call is1 - (1 - w/W)^r. Expected selections per call are r × w/W.
That is a deliberately narrow contract. If the pool changes between rolls, entries cannot repeat, a condition gates only part of the table, or a function can produce zero or extra items, these formulas are not a parser for the real file.
Why direct mode exists
Real tables can use range rolls, bonus rolls, entry or pool conditions, count functions, enchantment-aware functions, nested references, and edition-specific syntax. Derive the probability from the exact versioned file with those branches included, then enter the complete per-call result in direct mode. You can also use direct mode for a plainly labeled what-if scenario. The calculator never converts a filename into a rate.
Quantity and time remain separate assumptions
Average quantity per selection must come from the applicable count function or another documented input. Full cycle time must cover the complete repeatable activity: travel or setup, trigger, combat if relevant, collection, reset, and return to a comparable starting point. Expected quantity per hour combines these two user inputs with the calculated selection expectation; it does not estimate world-generation frequency or declare one farming route superior.
Preserve provenance with every shared URL
Record edition, exact game version, table path or source URL, data-pack or mod state, tracked entry, eligible weight sum, rolls, and any exclusions. A future change in the game file should create a new scenario rather than silently overwriting the older one. The evidence-first loot-table guide provides a review checklist and blank log schema.
What loot tables actually are
Java Edition ships loot-related JSON data, and the pinned 26.2 files cited below expose the exact records behind this page's fishing and mob examples. Their existence does not make every table a simple w/W problem. That mode is a calculator contract: use it only after your source establishes one unchanged eligible pool, fixed rolls, and repeated weighted selection with replacement. If the applicable file has conditions, functions, nested references, changing eligibility, or another selection rule, derive the complete probability first and use direct mode. The community loot-table referenceis useful for navigation, but the versioned file remains the evidence for any numeric input.
Read the cited fishing file in layers
The pinned Java Edition 26.2 fishing table references three sub-tables — fish.json,junk.json, and treasure.json — with relative weights of 85, 10, and 5. With no Luck modifier those weights sum to 100, so they are also the category percentages. The treasure entry is eligible only when the bobber's in_open_water predicate is true. Its positive quality value, alongside negative values for fish and junk, is what shifts weight toward treasure as Luck rises (Java 26.2 fishing table; Java 26.2 release). Category odds and within-category weights are separate layers — a treasure item's overall chance is the product of both.
For Java Edition 26.2, the community wiki documents a base internal wait of 5 to 30 seconds and a 5-second reduction per Lure level. Those figures describe the wait counter before environmental timing modifiers and the fish-approach phase; they are not a promise of total cast-to-catch time. Use a measured full cycle time for a Lure setup rather than converting those seconds into a loot probability. The pinned fishing file separately records the Luck-sensitive category weights (Fishing, Minecraft Wiki community reference). Keeping timing and selection probability as separate sourced inputs preserves their provenance.
Read Looting from the exact mob table
Java Edition 26.2 does not give every mob drop one universal Looting adjustment. The shipped data provides concrete counterexamples to the old “rare drop means +1 percentage point per level” shortcut:
- A zombie's rare-drop pool starts at 2.5%; Looting I uses 3.5%, followed by 1 percentage point per additional level (zombie table).
- A rabbit's foot starts at 10%; Looting I uses 13%, followed by 3 percentage points per additional level (rabbit table).
- A shulker shell starts at 50%; Looting I uses 56.25%, followed by 6.25 percentage points per additional level (shulker table).
The enchantment definition separately adds 1 percentage point per level to eligible equipment-drop chances when the attacker is a player (Looting definition). Other entries can use other functions. Therefore, classify the exact entry and read that version's table before entering a probability; the words “common,” “rare,” or “equipment” are not enough to choose a numeric adjustment by themselves.
A worked cumulative-probability example
Whatever the source of your per-call probability, repetition math is the same. For per-call chance p, the chance of at least one success within n calls is 1 - (1-p)^n. As a purely hypothetical example — an illustration, not a claim about any real table — suppose a complete table call gave your tracked item a 5% chance. At least one success within 14 calls has probability 1 - 0.95^14 ≈ 51%; reaching 90% takes about 45 calls (1 - 0.95^45 ≈ 90.1%); and the expected number of calls per success is1 ÷ 0.05 = 20. Note that after 20 calls — the long-run average — the chance of still having nothing is 0.95^20 ≈ 36%. Cumulative probability climbs steeply at first and then flattens, which is why the calculator reports threshold horizons instead of promising a finish line.
Limitations you should hold this page to
The numeric examples above are bounded to the cited vanilla Java Edition 26.2 records; the earlier Microsoft tutorial establishes only the Bedrock weighted-pool concepts it explicitly documents. Neither source is a promise about another edition, version, data pack, server, or mod. Record that scope with the probability. If any part of the environment changes, treat the prior value as unverified until you re-read the applicable file or reference instead of carrying the number forward by name alone.