Updated
Cartonization is the process of deciding which box a given set of items should be packed into — specifically, the smallest box they physically fit in, chosen from the packaging you actually stock. It runs per order rather than per product, because the right box for two items is not derivable from the right box for each one separately.
That is the whole definition. What makes it a subject rather than a sentence is that the calculation is genuinely hard, the data it needs is the data most operations do not have, and the answer it produces is what the carrier prices.
The instinct is to write it down as a lookup: this product goes in that box, three of those go in the medium carton. That works, and it keeps working right up until orders start combining SKUs.
The reason it stops is combinatorial. A catalogue of 200 products does not have 200 packing decisions in it; it has a decision for every combination of items and quantities that a customer might order. You cannot enumerate that in advance, which means the answer has to be computed at the moment the order arrives.
Cartonization is an applied instance of bin packing — given a set of objects and a set of containers, assign every object to a container while using as few containers as possible.
Bin packing is one of the foundational hard problems in computer science. Its decision version sits in Richard Karp’s 1972 list of 21 NP-complete problems, the paper that established the class of problems for which no efficient exact algorithm is known. In plain terms: as the number of items grows, the time required to guarantee the best answer grows faster than any polynomial. There is no clever implementation that escapes this. It is a property of the problem.
The version that matters for shipping is worse than the textbook one. Classic bin packing is one-dimensional — items have a size, bins have a capacity, and you are adding numbers. Packing a carton is three-dimensional: items have length, width and height, they can be rotated, and they have to occupy space without overlapping. Martello, Pisinger and Vigo’s treatment of the three-dimensional bin packing problem in Operations Research describes it as strongly NP-hard and, in their assessment, extremely difficult to solve in practice.
So exact optimality is off the table for anything running inside a fulfilment window. What is on the table is a good answer, quickly, and the gap between a good answer and the perfect one is small enough not to matter.
The standard approach is a greedy heuristic. Sort the items largest first, then place each one into the first container it fits in, opening a new container only when nothing existing will take it. That is First Fit Decreasing, and its close relative Best Fit Decreasing places each item into the fullest container that still has room.
These are not approximations in the hand-waving sense. Their worst case is bounded and proved. Johnson, Demers, Ullman, Garey and Graham established the worst-case performance bounds for the simple one-dimensional packing algorithms in SIAM Journal on Computing in 1974, giving First Fit Decreasing an asymptotic ratio of 11/9. The exact additive constant stayed open for decades until Dósa proved the tight bound to be FFD(I) ≤ 11/9 · OPT(I) + 6/9.
Read that as a practical guarantee. A greedy sort-and-place will never use more than about 22% more containers than the theoretically perfect packing, and on the small item counts of a typical ecommerce order it is usually identical to it. You do not need the optimal algorithm. You need the fast one with a known ceiling.
One trap is worth naming because it is the most common way a home-grown cartonization attempt goes wrong.
Adding up the volume of the items and finding the smallest box with more volume than that is not cartonization. It is a necessary condition, not a sufficient one. Three items totalling 584 cubic inches will not necessarily fit a 720 cubic inch box — an 81% fill ratio is high for irregular objects, and a single long item can rule out a box that has plenty of room by volume.
Volume is a fast pre-filter that eliminates boxes which certainly cannot work. Something still has to check whether the geometry actually closes.
Cartonization is only as good as three inputs, and operations usually have the first, sometimes the second, and rarely the third in a usable state.
Your packaging. The internal dimensions of every carton, mailer and envelope you stock, plus its maximum weight. Internal, not external — the difference is the wall thickness, and it is the difference between a box that closes and one that does not.
Per-item dimensions. Length, width and height for every SKU, as packed rather than as marketed. This is the constraint that decides whether cartonization is available to you at all, and it is where most operations stop.
I should be direct about how common that is, because it is the single best predictor of whether this is a short project or a long one. It is rare to find an account with valid, current dimensions on its catalogue. Anecdotally, about a quarter have some portion of them filled in, and even those are usually stale — entered once when the product was set up and never revisited through a packaging change or a supplier switch. The rest have essentially nothing.
The asymmetry with weight explains why. A weight is one number, a carrier demanded it, and a scale on the bench produces it. Dimensions are three numbers per SKU, nothing captures them unless you have bought a dimensioner, and no marketplace feed supplies them.
The order. Which items, in what quantities. That part you have.
ShipStation populates weight from several sources automatically and populates dimensions from none of them. Which is why a cartonization project is usually a data project first, and why the honest first question is not “what algorithm” but “do you have the catalogue”.
This is the part that turns a warehouse decision into a financial one.
Carriers bill on the greater of a parcel’s actual weight and its dimensional weight — volume divided by a fixed divisor, currently 139 across the major carriers, though USPS applies it only above one cubic foot, which means a parcel small enough to qualify for cubic pricing is never billed on dimensional weight at all. On anything light for its size, the box sets the price and the contents are irrelevant to it. How that calculation works and what a smaller box is worth covers the mechanics.
USPS adds a second, sharper mechanism. Cubic pricing charges purely on volume, in tenths of a cubic foot, and each tier is a price step. A box that lands in the 0.3 tier costs more than the same contents in a 0.2 box, regardless of weight. How cubic pricing works and when cubic beats standard Ground Advantage both turn on which tier the packing decision lands in.
So the packing choice is a pricing choice. Which is why solving packing and rating as two sequential steps loses money.
Every shipping platform rates a parcel that has already been described. You give it dimensions and a weight; it returns prices. The box is an input to rating.
That ordering is fine when the box is fixed. It fails when the box is a variable, because the cheapest box depends on which rate you would end up paying, and the rate depends on which box you chose. Each answer is an input to the other.
The clearest case is carrier flat-rate programmes. USPS Priority Mail Flat Rate and FedEx One Rate charge one price if you pack into their box. Whether that wins depends on whether your items fit their box, which is a cartonization question — and by the time any rate is fetched, you have already packed into your own carton and ruled it out. Why that is structural rather than a missing setting goes through it in full.
The general form: to actually minimise cost you have to generate the candidate packings, price each one against live rates, and pick the winner — packing and rating as a single decision rather than two. Anything that does packing first and rating second is optimising the second step against a first step it never questioned.
Three, with real arithmetic.
An order that fills an 18 × 14 × 10 carton. That is 2,520 cubic inches, so its dimensional weight is 2,520 ÷ 139 = 18.13, rounded up to a 19 lb billable weight.
Split the same contents across two 12 × 10 × 8 cartons. Each is 960 cubic inches, giving 960 ÷ 139 = 6.91, rounded up to 7 lb on UPS or FedEx. Two of them is 14 lb of billable weight, five pounds less than the single large box. On USPS the split does better still: at 960 cubic inches each box is under the one-cubic-foot threshold, so both bill on actual weight and dimensional weight drops out of the comparison entirely.
But two parcels means two base rates and two sets of surcharges, and one parcel means one. Which wins is not obvious from the dimensions alone — it depends on your rate card, the zone, and what each carrier charges as a floor. That is precisely why it has to be computed per order rather than decided once as a policy.
USPS cubic tiers step every tenth of a cubic foot. One tenth is 172.8 cubic inches, so the 0.2 tier ends at 345.6 cubic inches and the 0.3 tier at 518.4.
An 8 × 7 × 6 box is 336 cubic inches. That lands in the 0.2 tier, just under the boundary.
A 10 × 8 × 6 box — one size up, and a box a packer might reach for because it closes more easily — is 480 cubic inches. That is the 0.3 tier. Same contents, one tier more expensive, on every order that ships that way.
USPS rounds each side up to the nearest whole inch. So the 8 × 7 × 6 box above, if its true height is 6.2 inches once taped, is measured as 8 × 7 × 7.
That is 392 cubic inches, which is over 345.6, which is the 0.3 tier. A fifth of an inch of cardboard moved the parcel up a price step, without anyone choosing a different box.
That is the level of precision cubic pricing operates at, and it is why “roughly the right box” is not a strategy.
Broadly: rules, not computation.
Automation rules in ShipStation can apply a package based on criteria you defined in advance — a SKU, a weight band, an item count. That is genuinely useful for a narrow catalogue and it is the correct tool when the box really is a property of the product. Applying packages with automation rules covers how to build them.
The gap is structural rather than an oversight. Computing a packing plan requires the dimensions of every SKU in a catalogue the platform does not own, and building it means solving an NP-hard geometric problem for every merchant on the system. It is not a reasonable thing to ask of a horizontal platform.
That said, the position has moved. ShipStation’s Packing Recommendations, a beta in ShipStation Labs, computes a packing plan from your product dimensions and configured packages and builds the multi-package configuration in one click. It is a real answer to the hard half. What it does not yet do is run unattended at import or feed its result into rate selection — you invoke it per order, and by then the rate chain has already run. Where that sits relative to the rest of the splitting features.
This page is the problem rather than any one platform’s handling of it. How cartonization works in ShipStation specifically covers the four mechanisms that can put a box on an order, what each needs from your catalogue, and where each stops.
The symptoms are consistent, and they arrive in a particular order — the operator feels it first, patches around it second, and finds it on the invoice last.
It starts as a gut sense. Almost nobody arrives at this having diagnosed it. What they say is some version of I think I’m paying too much on shipping, without being able to point at where. That instinct is usually right. What is usually wrong is the size of it: they have a figure in mind for how much they are overpaying, and in the accounts I have looked at the real number is typically three to five times that. The gap is not because anyone was careless. It is because the cost is spread evenly across every order rather than concentrated anywhere a report would show it.
Then come the stop-gaps. The tell that an operation has felt this without naming it is the workarounds already in place. Some floors write SOPs for the common order shapes — if it’s two of these and one of those, use the medium carton — which is a reasonable response and genuinely helps on the combinations it covers. The difficulty is that SOPs have to be trained, training is only so successful, and the document covers the scenarios someone thought to write down rather than the ones that actually occur.
Where there are no SOPs, the same knowledge exists anyway as tribal knowledge, passed between packers. That works, and it is invisible, and it leaves with the person who holds it. One published review of exactly that situation — a meal-replacement brand whose catalogue combined in enough ways that no rule covered it — moved the average label from $9.33 to $8.49 by making the decision reproducible. The judgement was already good. The dependency was the problem.
Under time pressure, all of it degrades. Ask what a packer does on a busy afternoon and the honest answer is any of: reaching for the next size up because it closes faster, defaulting to whichever box is nearest, or applying an SOP that nearly fits. All of them are bad news and none of them is a discipline failure. A judgement made a thousand times a week against a clock is a process without a specification, and it will drift toward whatever is quickest.
On the invoice, it looks like nothing. This is what makes it survive. Parcels billed on dimensional weight rather than actual weight are the mechanical signature, and the diagnostic is an export of recent shipments comparing billed weight against actual — where the two diverge systematically, the box is setting the price rather than the contents. But there is no error, no failed label, and no report line for the box nobody considered. A packing decision that cost forty cents more than it needed to looks identical to one that did not.
Cartonization is choosing the smallest box a set of items actually fits into, computed per order. It is a three-dimensional bin packing problem, it is NP-hard, and it is solved in practice with bounded greedy heuristics rather than exact optimisation.
It needs internal packaging dimensions and per-SKU dimensions, and the second of those is the reason most operations cannot do it yet. The box it produces determines the dimensional weight and the cubic tier, which is to say it determines the price — and because rating happens downstream of packing, an operation that treats them as separate steps is optimising the cheaper of the two.
There is a self-assessment that runs on two standard ShipStation exports and tells you where your own orders are costing more than they need to — oversized boxes, services picked by habit, shipments the rules engine could not handle. It runs in your browser and nothing is uploaded.
Most of what it finds is fixable inside ShipStation. Where it is not, that is the point at which logic above the platform starts to be worth it — usually past 6,000 orders a month with a dedicated fulfillment team.
