Comparator Output: Fullness, Not Count

Verified: Java 26.3 / Bedrock 26.50 · 2026-09-16 · fullness formula and both modes documented without an edition split; reading quirks differ · Updated 2026-09-16

A storage monitor that lights a lamp when the barrel is nearly full, a self-stopping farm, an item sorter that reports back: all of them rest on one formula, and most of the confusion around it comes from thinking a comparator counts items. It does not. It measures how full the slots are, and this guide gives you the arithmetic the comparator calculator runs, the thresholds for every container size, and the traps that make a circuit read one level off.

The formula

An empty container outputs nothing. Any other container outputs the floor of one plus fourteen times its average fullness, where a slot's fullness is the number of items in it divided by that item's maximum stack size. Written out: signal = floor(1 + (sum of slot fullnesses ÷ slot count) × 14). Two consequences follow immediately. The first is that the very first item is the cheap one — a single cobblestone in a 27-slot chest is enough for signal 1, and so is anything up to 123 items. The second is that signal 15 means exactly one thing: every slot in the container holds a full stack. Nothing less reaches it.

Because the per-slot fractions are summed before they are averaged, how the load is spread across the slots never changes the answer. Twenty-seven slots of 32 cobblestone and thirteen full stacks plus one half stack both come to the same total, and both read 8. That total is the number worth carrying around, and the community name for it is the full-stack-equivalent.

Full-stack-equivalents

One item that stacks to 64 is 1 full-stack-equivalent. One that stacks to 16 — snowballs, signs, ender pearls — is 4, because sixteen of them fill a slot. One unstackable item, a minecart or a boat, is 64, because it fills a slot by itself. Add those up and the formula becomes signal = 1 + floor(14 × FSE ÷ (64 × slots)), which is what the calculator computes in whole numbers so nothing rounds twice.

The wiki's own examples fall straight out of it. Three ender pearls are 12. Sixteen ender pearls and 60 redstone dust are 124, and so are one minecart and 60 redstone dust. Three minecarts and 14 dirt in a five-slot hopper are 206, which reads 10 — and the next level up would need 229, so there is room to spare. This is also why a chest of tools and armour reads far higher than its item count suggests: unstackable gear is all full slots.

Every threshold

The least full-stack-equivalent that reaches each level is max(1, ceil(64 × slots × (level − 1) ÷ 14)). For 64-stackable items that figure is also the item count; divide by 4 for 16-stackable items, or by 64 for unstackable ones, rounding up each time.

Full-stack-equivalents. A furnace, blast furnace and smoker share three slots; a hopper, a hopper minecart and a brewing stand share five; a chest, barrel, shulker box and chest minecart share twenty-seven.

Read down a column and the steps are almost even: a chest needs 1,728 ÷ 14, about 123.4 full-stack-equivalent, per level, which is why its thresholds run 124, 247, 371 rather than in round numbers. The exception is the step from nothing to signal 1, which costs a single item. If a circuit only needs to know whether a container is empty, that step is free, and the fourteen expensive ones can be ignored.

The two modes, and the delay

Container reading is only half of the block. With no side inputs powered, a comparator passes its rear signal through unchanged. In comparison mode — the front torch down — it outputs the rear signal while both side inputs stay at or below it, and 0 the moment either side exceeds it. In subtraction mode, with the front torch up and lit, it outputs max(rear − max(left, right), 0): rear 9 with sides of 5 and 2 gives 4, and rear 4 against sides of 6 and 7 gives 0 rather than a negative. Either mode takes 2 game ticks, a tenth of a second, to pass a change along, including a change from one non-zero strength to another.

What this does not cover

Several blocks a comparator can read are not containers and do not use the fullness formula at all: a composter reports its compost level from 0 to 8, a cake 2 for each remaining slice out of seven, a cauldron its fill level from 0 to 3, a chiseled bookshelf the last slot placed into or taken from, a respawn anchor one of 0, 3, 7, 11 or 15 by charge, and a lectern floor(1 + ((page − 1) ÷ (pages − 1)) × 14), which makes a 15-page book read out its page number. The crafter is the one that looks most like a container and is not: it outputs the number of slots that are filled or disabled, from 0 to 9, regardless of how full those slots are.

The edition differences sit around the formula rather than inside it. In Java, a chest that cannot open — a solid block or a sitting cat above it — reads 0 no matter what is inside, while a shulker box can always be read; and a comparator reading through an intervening block that is itself powered to 15 outputs 15 regardless of the container, which is recorded as intended behaviour. Bedrock counts several non-conductive blocks, among them chains, pistons and copper grates, as comparator-conducting, so a reading can travel through geometry that Java would block. Where the two editions genuinely differ, this site states the difference rather than averaging it.

Sources

The fullness formula, the reverse formula, the minimum-items table and the non-container block rules all come from the Minecraft Wiki's comparator page (minecraft.wiki/w/Redstone_Comparator), read 2026-09-09. Every one of the 90 threshold cells above was independently recomputed from the formula and compared with the published comparator signal calculator at minecraftmaps.com/tools/comparator-signal-calculator, which agrees on all of them; its stated reverse formula, max(level, ceil(slots × 64 × (level − 1) ÷ 14)), is the one implemented here. The wiki types that same formula with a misplaced bracket, but its own worked example — 110 items for signal 9 from a three-slot furnace — evaluates the way both this tool and the table do. The recomputation lives in tests/mirror_comparator-calculator.py and runs before every deploy.