What 1D Bin Packing Actually Solves
A 1D bin packing calculator solves the one-dimensional bin packing problem: given a fixed bin capacity and a list of item sizes, assign every item to exactly one bin so that no bin exceeds capacity and as few bins as possible are opened. The "1D" tag means every item is described by a single scalar quantity — a weight, a length, a memory footprint, a workload figure — and the bin is described by a single capacity in the same unit. The objective is the minimum number of bins, with every item appearing once and nowhere else. The problem is documented as a classical operations-research formulation in Google's OR-Tools bin packing notes, which frame it as assigning each item to one of a set of equal-capacity bins so that no bin overflows and the total count of used bins is minimised.
Because bin packing is computationally hard in general, most practical tools, including the Bin Packing Calculator, apply a heuristic that runs in milliseconds on realistic lists and then report the lower bound any solver would have to beat. That trade-off is exactly what makes the page useful for quick planning: you give it a capacity and a list of sizes, and you get back an inspectable packing plan in your browser.
How First Fit Decreasing Packs the Items
The tool uses First Fit Decreasing, often abbreviated FFD. The implementation is fully deterministic and follows three rules in order: validate every item as a positive number no larger than the bin capacity, sort the list from largest to smallest while keeping the original order for equal sizes, and place each item into the earliest opened bin that still has enough remaining capacity, opening a new bin only when no existing bin fits.
Sorting first matters because it changes which combinations get tried. Placing the largest items before the small ones leaves the tightest decisions for the start of the run, where the bins are still empty and any subsequent item has the maximum possible remaining room. Equal sizes retain their input order, and "first" always means the bin opened earliest in the run, so two readers with the same capacity and the same list always get the same plan. That reproducibility is what makes a saved example auditable — you can rerun the page with the same inputs and confirm that an item landed in a particular bin for a specific reason rather than because of an internal random tie-break.
FFD does not guarantee the globally smallest bin count. Bin packing can hide a better arrangement behind an early placement that fills a bin almost perfectly but blocks a later, slightly different pairing. The page does not claim optimality; it only exposes the plan, the per-bin totals, and the lower bound so you can judge how much slack remains.
Run a 1D Bin Packing Plan in Three Steps
- Enter the common capacity available in every bin. Use the same unit you will use for every item, since the model compares numbers as scalars without conversion.
- List one item per line as either a plain size or as "label, size" using a single comma. Rows with only a number receive an automatic label, and rows with custom labels use one comma as the separator; commas inside the label text are outside the simple import format.
- Run First Fit Decreasing, inspect every bin's assignment, used and remaining capacity, overall utilization, and the ceil(total size / capacity) lower bound, then copy the plan if you want to paste it into a worksheet, loading draft, memory-allocation example, or operations-research exercise.
The list accepts at most 1,000 items, every item must be greater than zero and no larger than one bin, and processing stays entirely in the browser. Negative entries or oversized items return a clear error rather than being silently dropped, so a plan that finishes always has a valid input behind it.
Reading the Lower Bound, Bin Count, and Utilization
Three numbers in the result deserve attention, and each one tells a different story about the plan.
The bin count is the number of bins the FFD run actually opened. The lower bound is the smallest integer that is at least the total item size divided by the bin capacity, written as ceil(total / capacity). No plan, no matter how clever, can use fewer bins than that bound, because the bins cannot hold more total size than their combined capacity. In a quick example with capacity 10 and sizes 7, 5, 5, 4, 3, 3, 2, the total item size is 29, so the lower bound is ceil(29 / 10) = 3 bins. The FFD run also opens exactly 3 bins: one holding 7 + 3 = 10, another holding 5 + 5 = 10, and a third holding 4 + 3 + 2 = 9, so the plan matches the bound in this case.
Utilization divides the total item size by the total capacity of the opened bins. In the example, that is 29 / 30, or about 96.67%. Utilization close to 100% means the heuristic managed to leave very little unused space across all bins, while a noticeably lower utilization means the run left meaningful slack that a different arrangement might have recovered.
Matching the lower bound does not by itself prove optimality, because individual item combinations also constrain feasibility. A plan can match the bound and still be improvable in principle, while another plan that exceeds the bound by one bin has simply hit the limits of FFD on that particular ordering.
What the Model Leaves Out
| In scope | Outside the model |
|---|---|
| One scalar size per item | Length, width, height, orientation |
| Per-bin capacity limit | Stack strength, centre of gravity |
| Each item assigned to exactly one bin | Splitting items across bins |
| Bin count and size-based lower bound | Optimality certificate |
| Deterministic FFD placement | Hazardous-materials separation, axle limits |
Sizes are abstract scalar quantities. They can represent weight, memory, workload, length, or any other one-dimensional resource, provided capacity and every item share the same unit. They do not represent three-dimensional box dimensions, balance, fragility, stacking strength, hazardous separation, or vehicle axle limits. Container loading in the broad physical sense needs specialist software and safety rules.
The tool does not split items, combine capacities, reserve space, or apply values and priorities. A request to "place this 12-unit job first" or "treat two bins as one larger bin" sits outside the simple FFD model, even though those are common in real scheduling work.
Common Use Cases for a 1D Plan
| Use case | Why 1D bin packing fits | Constraint to validate separately |
|---|---|---|
| Memory allocation example | Items as processes, bins as equal RAM slabs | Process priorities, fragmentation, kernel overhead |
| Cutting stock draft | Lengths against a stock length | Kerf, grain direction, blade width |
| Workload batching | Job sizes against a shift or batch capacity | Sequence, setup times, deadlines |
| Operations-research teaching | Reproducible FFD plan for class exercises | Optimal integer-programming solver for production claims |
For logistics, cloud capacity, manufacturing, or safety-critical loading, use a validated domain solver and confirm the final assignment. The page is transparent educational and planning assistance, not a proof of minimum cost or safe loading.
When to Reach for a Different Solver
The 1D model is a foundation, not a destination. If you need to cut fixed stock lengths with blade kerf, you are looking at a cutting stock problem with explicit waste. If you need to pick a subset of items that fits one capacity to maximise value, that is the 0/1 knapsack problem. If you have one capacity shared by several knapsacks with a different objective, you are in multiple-knapsack territory. If you need to schedule jobs on machines with time windows and priorities, you are in scheduling, not bin packing. The Bin Packing Calculator is a transparent starting point for exploring heuristics and comparing ordering effects; it is not a substitute for a validated production solver when constraints become physical, regulatory, or financially binding.
Two practical signals tell you it is time to escalate. The first is when utilization on a representative plan stays well below the lower bound minus a small slack, which suggests FFD is leaving easy savings on the table. The second is when the plan looks good on paper but has to satisfy real-world rules — orientation, stack height, weight distribution — that the scalar model cannot see. In both cases, the right move is to capture the plan as a draft and hand it to a domain solver that knows the rules you actually need.