A 2D bin packing calculator assigns rectangular items to rectangular bins using two dimensions per item, but many real-world tasks that people label "2D" reduce cleanly to a single size per item and are solved just as well by a deterministic scalar packing tool. The Bin Packing Calculator does exactly that: it takes a common bin capacity, accepts up to 1,000 labelled item sizes in the same unit, applies the First Fit Decreasing (FFD) heuristic, and reports every bin's contents, used and remaining capacity per bin, overall utilization, and a simple size-based lower bound. FFD sorts the items largest first and then places each item into the earliest already-open bin that still has room; a new bin opens only when no existing bin can take the current item. Equal sizes retain their original input order, so "first" always means the earliest open bin, and the same input reproduces the exact same plan. All processing happens in the browser, so nothing is uploaded.
What "2D Bin Packing" Usually Means vs. Scalar Packing
True 2D bin packing treats every item as a rectangle with a width and a height and asks for the minimum number of equal-sized rectangular bins that hold them all, usually allowing 90-degree rotation. Geometry matters: two 6×8 rectangles have a combined area of 96, well under one 10×10 bin's area of 100 per bin, but two of them placed side by side measure 12×8, which no longer fits. Pure area accounting misses those clashes, and a genuine 2D solver has to respect them, as documented in Google OR-Tools' bin packing reference.
Scalar packing collapses each rectangle, or each item, to a single size — total area, longest side, weight, memory footprint, or any other one-dimensional resource — and ignores the second dimension. The Bin Packing Calculator lives in this scalar family. When the "2D" problem is really a 2D layout problem with rotation, orientation, balance, or stacking rules, the scalar tool will not enforce those rules. When the problem is genuinely a list of one-dimensional quantities that happen to come from a 2D source (sheet area used, length of pipe needed, batch weight, memory blocks), scalar packing is exact and faster. That distinction is the reason the same query — "2D bin packing calculator" — can reasonably send some readers to a geometry-aware solver and others to a deterministic 1D packing tool. Knowing which problem you actually have is the first decision to make.
How to Pack Items with the Bin Packing Calculator
Using the Bin Packing Calculator is a three-step workflow that runs entirely in your browser.
- Enter the common capacity available in every bin. Use a single positive number; every item you list later must use the same unit (kilograms, square meters, megabytes, linear meters, or any abstract scalar).
- List one item per line. A line can be just a number, in which case the tool assigns an automatic label. To keep your own label, write it as label, size — for example, Shelf-A, 42. Make sure every size is greater than zero and no larger than the capacity; lines that fail the check return a clear error rather than being silently dropped.
- Run FFD, inspect every bin, then copy the plan. The output shows the bin count, the items inside each bin, the used and remaining capacity, the overall utilization (total item size ÷ total capacity of opened bins), and the size-based lower bound ceil(total size ÷ capacity). If the plan looks reasonable for your planning purpose, copy it for a worksheet, loading draft, memory-allocation example, or operations-research exercise.
Because the algorithm is deterministic and stable on equal sizes, the same input list always reproduces the same assignments. That makes saved examples auditable: you can re-run a plan after editing the list and see exactly which item moved, and why.
A Worked Example: Six Items into 10-Capacity Bins
Here is a single small worked example to show the algorithm in motion. Capacity is 10 and the items are 7, 5, 4, 4, 3, 2 — six values, all in the same unit.
Step 1 — sort descending. FFD starts by sorting items from largest to smallest. The sorted list is 7, 5, 4, 4, 3, 2.
Step 2 — open and place, in order.
- Place 7. No bins exist yet, so open Bin 1 and put 7 in it. Bin 1 has 10 − 7 = 3 remaining.
- Place 5. 5 is greater than Bin 1's remaining 3, so Bin 1 cannot take it. Open Bin 2 and put 5 in it. Bin 2 has 5 remaining.
- Place 4. 4 is greater than 3 (Bin 1 cannot take it), but 4 ≤ 5 (Bin 2 can). Place 4 in Bin 2. Bin 2 now holds 5 + 4 = 9, with 1 remaining.
- Place 4. 4 > 3 (Bin 1), 4 > 1 (Bin 2). Open Bin 3 and put 4 in it. Bin 3 has 6 remaining.
- Place 3. 3 ≤ 3 (Bin 1 fits exactly). Place 3 in Bin 1. Bin 1 now holds 7 + 3 = 10, with 0 remaining.
- Place 2. 2 > 0 (Bin 1 full), 2 > 1 (Bin 2 full). 2 ≤ 6 (Bin 3 fits). Place 2 in Bin 3. Bin 3 holds 4 + 2 = 6, with 4 remaining.
Final bins: Bin 1 = {7, 3} (used 10, remaining 0); Bin 2 = {5, 4} (used 9, remaining 1); Bin 3 = {4, 2} (used 6, remaining 4).
Step 3 — sanity checks. Total item size is 7 + 5 + 4 + 4 + 3 + 2 = 25. Total capacity of opened bins is 3 × 10 = 30. Utilization is 25 ÷ 30 ≈ 83.33%. The size-based lower bound is ceil(25 ÷ 10) = ceil(2.5) = 3 bins. FFD produced exactly 3 bins, so this run matched the lower bound — but that match does not by itself prove optimality, because individual item combinations can also constrain feasibility. Run the same numbers through the Bin Packing Calculator to confirm.
Reading the Output: Bins, Utilization, and the Lower Bound
The bin count is the total number of bins the heuristic opened. In the worked example above it is 3.
Per bin, the tool lists the items assigned to that bin, in the order they were placed, and the used capacity (sum of items in the bin). Remaining capacity is capacity minus used capacity, and it represents unused space inside the scalar model — not necessarily recoverable physical volume. Used plus remaining always equals the original capacity for every bin the tool reports, because the algorithm rejects any placement that would overflow.
Utilization is total item size divided by the total capacity of opened bins. With 25 items packed into 30 capacity units, utilization is 25 ÷ 30 ≈ 83.33%. Utilization near 100% means little wasted space; utilization far below 100% usually means one bin is mostly empty and the input could be reorganized. Try sorting the input differently, or pair very small items with very large ones to close the gaps.
The size-based lower bound is ceil(total item size ÷ capacity). It is a hard floor: no plan can use fewer bins than this number, because the items would not physically fit. FFD does not always match the lower bound, and even when it does, the match is not a certificate of optimality. Individual combinations of items can force extra bins beyond the size bound. The interface presents the bound and the heuristic side by side without turning either into a false guarantee.
When Scalar Packing Solves 2D-Adjacent Problems
Not every problem that arrives labelled "2D" needs a geometry solver. Most readers searching for a 2D bin packing calculator have one of three jobs on their desk: cut rectangles from sheets, group workloads into equal batches, or pack labelled items where the second dimension does not matter. The first job needs a real 2D solver; the second and third are scalar problems in disguise. The table below separates those cases so you can decide which tool fits.
| Problem | Best fit | Why |
|---|---|---|
| Cut rectangles from a fixed sheet | Dedicated 2D container-loading solver | Width × height and 90° rotation change feasibility |
| Group workloads into equal batches | Bin Packing Calculator | Each workload has one size; all bins are equal |
| Pack labelled items into batches | Bin Packing Calculator | Scalar sizes, equal bins, FFD is enough |
| Load physical boxes into a vehicle | Specialist container-loading software | Balance, stacking, axle limits, safety rules apply |
| Schedule tasks into time slots | Scheduling or knapsack solver | Capacities, values, and priorities differ from plain bin packing |
The exact figures for the scalar rows always come from the tool itself; the qualitative direction in the right column is what matters when choosing an approach. For a primer on the 1D scalar case written from a slightly different reader angle, see the 1D Bin Packing Calculator: Pack Sizes into Bins guide. The same engine, the same FFD rule, just framed for a different workflow.
Limits and Where to Use a True 2D Solver
Three categories of limits apply to the Bin Packing Calculator and are worth knowing before you build a workflow around it.
Input limits. Up to 1,000 items per run. Every size must be greater than zero and no larger than one bin. Capacity must be positive. Rows with only a number get automatic labels; rows with custom labels use exactly one comma between label and size. Commas inside labels are outside the simple import format. Items that fail validation return a clear error rather than being silently dropped.
Algorithmic limits. FFD does not guarantee the globally smallest bin count. Bin packing is computationally hard, and a locally sensible early placement can prevent a better later combination. The displayed lower bound is a size bound — no plan can beat it, but matching it does not by itself prove the plan is optimal. The tool does not split items, combine capacities, reserve space, or apply values and priorities; those are different problems (cutting stock, knapsack, multiple-knapsack, scheduling) with different objectives, and the Lehigh analysis of cutting stock problems (An Analysis of Cutting Stock Problems) shows how quickly objectives diverge once you allow leftover stock to be reused.
Physical limits. Sizes are abstract scalars. They can stand for weight, memory, workload, length, or another one-dimensional resource as long as capacity and every item share the same unit. They do not represent three-dimensional box dimensions, orientation, balance, fragility, stacking strength, center of gravity, hazardous separation, or vehicle axle limits. "Container loading" in the broad physical sense needs specialist software with safety rules; the Bin Packing Calculator is transparent planning assistance, not a proof of safe loading or minimum cost. For logistics, cloud capacity, manufacturing, or safety-critical loading, run the plan through a validated domain solver and confirm the final assignment. The educational value of a deterministic, inspectable plan is real; the operational value depends on the constraints you still need to enforce elsewhere.