How to sell by weight in WooCommerce: the four methods compared

WooCommerce cannot sell by weight out of the box, and the reason is structural rather than a missing setting: the product weight field lives under the Shipping tab and feeds carrier rate calculations only — WooCommerce's own documentation never connects it to price. Add the whole-number quantity box and piece-based stock and you have three separate gaps to close before a customer can buy 750 g of anything. Four approaches close them to different depths: product variations, a measurement price calculator, a unit-price display plugin, or a dedicated by-weight pricing plugin.

Which one you need depends on how deep the gap goes for your catalog, and that is the question this page answers. We build By-Weight Pricing for WooCommerce, so method four is our category — which is exactly why the comparison below spends most of its space on where each method breaks, quoting the official WooCommerce documentation for the limitations that vendor tutorials leave out. Checked against WooCommerce 10.9.4 and the current extension docs in July 2026.

Why can't WooCommerce sell by weight natively?

Because selling by weight is four problems, and core solves none of them. Weight in WooCommerce is a shipping attribute; price, quantity input and inventory all assume discrete pieces.

Price

Weight sits in the Shipping tab and feeds carrier rates. Nothing in core multiplies price by weight.

Input

The core quantity box steps in whole units. "0.75" needs a changed step, server-side validation, and cart and checkout handling.

Inventory

Stock decrements one unit per item sold. "38.5 kg of Parmesan left" has no representation in core.

Unit price

The per-kilogram figure consumer law requires next to the selling price is not rendered anywhere by core.

The decimal-quantity gap is not on the roadmap either. WooCommerce's public feature-request board carries an open request to allow three-decimal precision on weights and prices; as of July 2026 it sits at two votes, which tells you how much pressure core is under to change. The fourth layer is the one most guides never mention: in the EU and the UK, showing the price per kilogram next to the selling price is a legal duty, not a nicety — the rules and the April 2026 UK deadline are set out in unit pricing laws for online stores.

What are the four ways to sell by weight in WooCommerce?

Variations fake it with fixed packs, measurement calculators compute a linear price from any measurement, unit-price plugins only display a per-kilogram figure, and by-weight pricing plugins treat weight as the unit of sale end to end. The differences that matter are capability differences, not price differences.

When are product variations enough?

When you sell a handful of fixed pack sizes at prices that rarely change — 250 g, 500 g, 1 kg — a variable product with a weight attribute is genuinely the right answer, and it costs nothing. Create the attribute, price each variation by hand, done.

It stops working in four predictable ways. A customer who wants 700 g cannot have it. Every price change is manual across every variation of every product, so the effective per-kilogram price drifts out of alignment between pack sizes without anyone noticing. Stock still counts packs, which diverges from reality the moment you cut from a wheel or a carcass. And the shop page shows a price range — "€4.50 – €18.00" — instead of a comparable figure, which is bad for shoppers and worse for machines: a parent price range with no per-variation detail is one of the documented reasons AI shopping agents drop a WooCommerce product from a comparison.

Add a second attribute — cut, thickness, grind — and the variation count multiplies rather than adds. That is usually the point at which stores start looking for method two or four.

What does a measurement price calculator actually do?

It computes a price from a measurement the customer enters, and it is built for made-to-measure goods rather than food sold by weight. The official Measurement Price Calculator extension documents two modes: quantity-based, where the customer enters a measurement and the calculator works out how many boxes or units are needed, and user-defined, where you set a price per measurement and the total is calculated from what the customer types. It covers seven measurement families — dimensions, area, perimeter, surface area, volume, weight and room walls — and in user-defined mode it can deduct the measured quantity from inventory instead of decrementing a single unit.

For flooring by the square metre, fabric by the metre or mulch by volume, that is the correct tool and nothing else comes close. For weighted goods it runs into limits the documentation states plainly:

• Bracket pricing is parent-level only. Pricing table rules "can currently only be defined at the parent product level", so a variable product cannot carry different per-kilogram brackets per variation.
• Calculated inventory and Product Add-ons conflict. The docs state calculated inventory cannot function alongside Product Add-ons because of the pricing manipulation involved.
• Composite Products and Product Bundles are incompatible. A composite product cannot contain a measurement product, because a measurement product cannot be enabled for a specific variation. Name Your Price and WISDM Customer Specific Pricing are listed as incompatible too.
• No wastage model. Sold weight is assumed to equal delivered weight — which is false for bone-out butchery, rind on cheese, and roast loss on coffee.

The area and volume machinery is also overhead you never touch if all you sell is weight.

What does a unit-price display plugin solve?

Exactly one thing: printing the legally required base price next to the selling price. These plugins divide pack price by pack weight and render "€29.90/kg" — quantities stay whole, packs stay fixed, stock stays in pieces. The mechanics of that division, including the shipping-weight trap hidden inside it, are in how to show a price per kg on every WooCommerce product.

That is the right choice when your catalog is genuinely fixed packs and your only gap is compliance. It is also the method with the shortest runway. The moment a customer should be able to choose a weight, or a price should follow a weight, there is no machinery here to extend — it is a display layer sitting on top of ordinary WooCommerce products, and moving past it means replacing it rather than configuring it.

What does true by-weight pricing add?

It makes weight the product's actual unit of sale across all four layers instead of one. On the product page the customer gets a weight field with a per-product minimum, maximum and step interval, and the price recalculates live as they type. Date-scheduled rules let a per-kilogram price change for a season or a promotion without editing products. A wastage percentage models the gap between sold weight and delivered weight, so the customer sees the actual weight they will receive after trimming. And the per-kilogram figure renders across product pages, shop loops and the cart — including on ordinary fixed-pack products, which is what makes the compliance layer storewide rather than limited to the products using the calculator.

Our own plugin sits in this category, so the honest limits are worth naming: it is weight-only by design, so a store pricing by square metre or cubic metre needs method two instead, and weighted products lose the one-click ajax add-to-cart flow because the customer has to choose a weight on the product page first. The chosen weight also sits beside WooCommerce's quantity rather than inside it, which is a deliberate architectural call — what happens when you put decimals in the quantity box instead traces exactly what core does and does not tolerate. The unit coverage matters more than it sounds — By-Weight Pricing carries 40-plus weight units with automatic gram-to-kilogram display switching, which is what makes a store work in both a metric and an imperial market without maintaining two catalogs.

Which method should you pick?

Three questions settle it, usually in under two minutes.

1. 1

   Do customers need to choose their own quantity?

   No, fixed packs only: use variations, or a unit-price display plugin if you legally need a price per kg. Yes: keep going.

2. 2

   Is the quantity a weight, or a dimension?

   Dimension (m², m³, metres, linear metres): a measurement price calculator is the right category. Weight: keep going.

3. 3

   Do you need wastage, scheduled per-kg rules, per-variation unit prices, or a storewide price-per-kg display?

   None of them, plain price × weight is enough: a measurement calculator in user-defined mode works. Any of them: a dedicated by-weight pricing plugin.

The one trap in that sequence is answering question one for today rather than next year. Moving from variations to by-weight pricing later means re-cutting the catalog, because fixed packs and weight-priced products are different product structures — not a setting you flip. If your catalog is meat, the butcher's version of this setup works through the yield and pricing maths that sits underneath those choices.

What do most sell-by-weight guides leave out?

Four things, and each one turns into support tickets rather than a broken page. They are the reason two stores with identical-looking requirements end up on different methods.

• Wastage. When delivered weight is less than sold weight — bone-out cuts, cheese rind, roast loss on coffee — the customer either sees the actual weight up front or disputes the order later. Only a plugin that models it can show that number.
• Catch weight. When the final weight is only known after cutting or packing, as with whole fish, roasts or farm boxes, you need estimated-versus-final billing on top of weight pricing. That is a payment-capture problem as much as a pricing one.
• Decimal quantities done halfway. Nearly every "just add this snippet" tutorial changes the quantity input's step and stops there, leaving server-side validation and stock decrement untouched. The product page looks right and the cart breaks at checkout.
• Unit-price law on category pages. A variable product's price range on a shop loop is not a unit price, so a store can be fully compliant on product pages and still non-compliant everywhere else — the trap covered in unit pricing laws for online stores.

There is a fifth for anyone selling precious metals or spices into non-Western markets: traditional units. Gold priced per tola, baht, don or jin is normal in large parts of Asia and the Middle East, and a plugin that only understands kilograms and pounds cannot express the price your customers expect to read. Check the unit list before the feature list.