Methodology

Every calculator converts your inputs to SI base units — metres, square metres, cubic metres and kilograms — does all of its arithmetic there, and converts back only when a result is displayed. Nothing is calculated twice in two unit systems, so switching between feet and metres cannot change an answer beyond display rounding.

Unit conversions are dimension-checked: the engine will not convert a length into an area, and a mismatched conversion is an error rather than a silently wrong number.

Measurement fields accept the way people actually read a tape. All of these are understood and mean the same thing: 8' 6", 8 ft 6 in, 102", 8.5 (in imperial mode), and 2.59m. Fractions work too — 3' 4-1/2".

Small dimensions such as tile, brick and paver sizes default to inches or centimetres rather than feet or metres, because that is how those products are specified. The unit hint inside each field shows which is being assumed.

Two different kinds of rounding happen, and we keep them separate:

• Display rounding shortens a number for reading. It never feeds back into a calculation — the full-precision value is what continues through the maths.
• Purchase rounding converts a required quantity into whole things you can buy, and always rounds up. You cannot buy 0.4 of a bag.

Purchase rounding uses a small tolerance so that floating-point noise cannot add a phantom unit. Without it, 27 ft³ divided by a 0.6 ft³ bag yield computes as 45.000000000000014 and would sell you a 46th bag you do not need. Exact multiples are tested for every purchasable unit on the site.

Where a material is sold in packages, the calculator resolves the requirement into that package: bags, boxes, bundles, sheets, packs, rolls or pallets. It then shows what those packages actually provide and how much is expected to be left over, so an awkward rounding is visible rather than buried.

Package sizes are never assumed when they are not standardised. Tiles per box, bricks per pack, blocks per pallet and sod coverage all vary between suppliers, so those fields ask you for the number and give a loose count if you leave them empty.

Waste percentages are recommendations, not constants. Every one is shown, editable, and explained by what actually generates the waste — usually cuts. A straight tile layout in a square room wastes little; a diagonal layout cuts every edge tile and wastes far more. The presets exist to save you a guess, not to replace your judgement.

A few calculators deliberately add no waste percentage. Paint is the clearest example: rounding up to whole tins already leaves slack, and stacking a waste factor on top routinely over-orders by a full gallon.

Where a constant materially changes the answer, it is a field on the page rather than a hidden number in our code. Paint spread rate, bag yield, bundle coverage, box coverage, mortar joint width, gravel and soil density, and sod roll size are all inputs you can override with the figure printed on your product.

Each calculator lists its assumptions in full underneath, with the source where one exists. If a default comes from a specific manufacturer's data, we say so rather than presenting it as an industry standard.

Some of the most-quoted figures in this field are approximations that vary by 20–40% in practice. Gravel density changes with stone type, gradation and moisture. Topsoil weight changes dramatically when wet. Paint spread rate depends on the surface as much as the paint. Bag yields differ between standard and fast-setting mixes.

Where this is true, the calculator offers labelled presets with their values visible, lets you turn a derived figure off entirely (weight estimates, for instance, can be disabled rather than guessed), and says in the assumptions that your supplier's number is the authoritative one.

Brick, block, paver, sheet and bag sizes differ by country. Nothing in the engine assumes US dimensions: regional presets are offered as conveniences and clearly labelled, and the custom dimension fields are always authoritative.

Where a widely-quoted rule of thumb disagrees with the geometry, we show the geometry and explain the discrepancy. The brick calculator is the clearest case — a 7⅝ × 2¼ in brick with a ⅜ in joint genuinely gives 6.86 bricks per square foot, while the familiar 6.75 figure assumes a nominal 2⅔ in course height and a slightly fatter bed joint.

Every calculator carries a semantic version and a review date, both printed beneath its title. The version increments whenever a formula or a documented assumption changes, so a result you shared last month can be traced to the logic that produced it. The most recent review across the library was 2026-09-18.

Formulas are covered by golden-value tests: hand-verified figures checked against published industry references and, where possible, cross-checked against independent calculators. These include the awkward cases — exact package multiples, openings subtraction, unit round-trips, pitch conversions and multi-area accumulation.

The shared engine is pure and has no dependency on the interface, which means the same tested code produces the number whether it is rendered on a page, printed, or shared through a link.

Area-based counts cannot know your layout. A drywall sheet count is correct on area but cannot see that one wall is an inch wider than your sheet is long; a brick count assumes a single-wythe wall in stretcher bond; a roof calculation assumes a gable unless you add sections. Each calculator states its own limitations in the assumptions block.

More broadly, ProjectCalc estimates quantities and nothing else. The disclaimer sets out what is deliberately out of scope, including all structural and code-compliance questions.

If you find a mistake, please tell us — with the share link from the calculator if possible, since it encodes your exact inputs. Corrections to the maths are the highest-priority work on this site. Contact details are here.