Paver Calculator

Face area, waste, then the round-up

A paver count is one division and one allowance. The patio's area in square feet is divided by the area one paver's face covers — its width times its length in inches, divided by 144, the square inches in a square foot (12 × 12, plain arithmetic on the definition of the foot). For the worked patio, one 6 × 6 in paver occupies 36 ÷ 144 = 0.25 sq ft, so the 120 sq ft patio needs 480 pavers exactly. The 10% cutting allowance lifts that to 528 — and because that lands on a whole number, the purchase is 528 pavers with none spare; odd areas round up instead. Underneath, a 1 in bedding layer is 10 cu ft = 0.37 cu yd of sand — the same area × depth arithmetic the aggregate tools use. Every computed figure on this page was produced when the page was built by the same paverEstimate function the form above runs in your browser, or by arithmetic on the unit definitions and the validation limit that engine itself imports; the example inputs are typed, the results never are, so the copy cannot disagree with the tool.

The one input on this page that is a judgment rather than a measurement is the waste percentage. What it models, why it is applied before the round-up rather than after, and how to choose a figure for a bordered, diagonal, or curved layout are the subject of the site's guide Waste factors, explained. Read it before changing the default. The rest of this page explains what the calculator does with the numbers you give it, stage by stage, and how to read what comes back.

What the calculator computes, stage by stage

Every estimator on this site follows the five-stage pipeline documented on the methodology page. The paver tool runs all five for the pavers and a shortened chain — geometry only — for the sand beneath them.

1. Geometry. Length times width gives the patio footprint in square feet. If you filled the total-area field instead, that figure is taken as the footprint and the length and width are ignored — the form sends the engine one or the other, never both. In metric mode the meters and square meters you type are converted to feet and square feet first, through the exact definitions listed below, so the arithmetic downstream is identical in both systems. Nothing is deducted: whatever area reaches the engine is treated as the finished paved surface.
2. Coverage. The footprint is divided by the face area of one paver: width in × length in ÷ 144. On most tools this divisor is a manufacturer or industry figure held in the site's materials data with its source; pavers are deliberately different. There is no standard paver, so that file holds no paver constant — it records paver size as a user input — and the divisor comes entirely from the two face dimensions you type. Nothing here is cited because nothing here is sourced: it is your paver, measured. The result of the division is the net count, fractional and unrounded.
3. Waste. The net count is multiplied by (1 + waste% ÷ 100). The prefilled 10% is a trade convention, not a manufacturer figure: the materials data file records that paver cutting follows the tile and flooring convention for border cuts, and labels it adjustable. The percentage is applied to the count, before any rounding, so the margin is counted exactly once. The waste guide covers what the allowance does and does not cover.
4. Package rounding. A paver is its own package, so the waste-adjusted count is rounded up to the next whole paver: ceil(adjusted count). This is the only rounding anywhere in the chain. The spare — the fraction of a paver bought beyond the adjusted count — is always less than one here, because the package is a single unit; the engine does not model pallets or bundles, so if your supplier sells by the pallet, the round-up to a whole pallet is yours to apply to the headline count. An exact fit does not buy a phantom paver, either. Binary floating point cannot always hold an exact product: a 10 × 10 ft patio in 12 × 12 in pavers has a face of exactly 1 sq ft and needs 100 pavers net, and 100 × (1 + 10 ÷ 100) evaluates to 110.00000000000001, where the exact answer is 110; a naive ceiling on that value would buy 111. The engine treats a count within one part in a billion of a whole number as an exact fit, so the purchase is 110 pavers with 0 spare — the same guard the methodology page demonstrates.
5. User-priced cost. If you type a price per paver, the cost line is the rounded count times that price — the count you buy, not the adjusted figure. The site never supplies, averages, or suggests a paver price; leave the field blank and the line does not appear.

The bedding line runs beside that chain rather than through it. The engine multiplies the same footprint by the bedding depth converted to feet — area sq ft × (depth in ÷ 12) — for cubic feet, then divides by 27 for cubic yards. No waste is applied to it and it is not rounded to whole yards: it is the bare volume of a layer of that depth over that area. A depth of zero removes the line altogether.

Why each input matters

Patio length and width set the footprint, and every count downstream scales with their product: double either and the net count doubles before rounding. Both go in as decimal feet, so a tape reading in feet and inches is converted first — the feet & inches calculator does that for awkward readings. The two fields are interchangeable; only their product reaches the engine.

Total area is the alternative footprint. An L-shaped, notched, or curved patio has no single length and width, so total it with the square footage calculator and paste the result here. When this field holds a value it wins: the length and width fields are ignored until it is cleared, which is worth remembering if a count refuses to move when you edit the dimensions.

Paver width and length go in as inches (centimeters in metric mode), and their order does not matter — a 4 × 8 in paver and an 8 × 4 in paver have the same face. Read them from the product's specification, not from a nominal name: the materials data file holds no paver sizes precisely because product lines differ, and the placeholders in the form are suggestions only. The engine accepts face edges up to 120 in, a validation limit it shares with the tile engine; anything larger is rejected as out of range rather than silently estimated. These two fields are also where the largest unit slip on this page happens, covered under misreadings below.

Sand bedding depth touches only the sand line. The form's default of 1 in is a common screeding depth offered as a starting point — base design is your project's call, as the FAQ puts it — and the volume moves in exact proportion to whatever depth you enter. It has no effect on the paver count.

Waste multiplies the count, so a change of a few points moves the adjusted figure proportionally and the purchase by whole pavers. It is a percentage of the paver count, applied once; it does not touch the sand. Price per paver only ever multiplies the final count and never feeds back into the quantity.

The units toggle changes what the fields expect and how the result is presented, not what is computed. In metric mode, meters are divided by 0.3048, square meters by 0.09290304, and centimeters by 2.54 — all exact definitions — before the engine sees them, and the result panel reports the footprint in m² and the bedding in m³ with cubic yards beside it.

The figures this page relies on

• Default waste, 10% — a trade convention recorded in the site's materials data, where it is labelled a convention because no primary source publishes a universal figure; the file notes that paver cutting follows the tile and flooring convention for border cuts. Adjustable in the form.
• Square inches per square foot, 144 — arithmetic: 12 in per ft, squared. It turns the paver's face in square inches into square feet.
• Inches per foot, 12, and cubic feet per cubic yard, 27 — definitions, exact; used by the bedding line.
• Meters per foot, 0.3048; centimeters per inch, 2.54; square meters per square foot, 0.09290304; cubic meters per cubic foot, 0.028316846592 — exact definitions of the international foot and inch and their square and cube, used only to convert metric entries in and to present metric results back out.
• Edge limit, 120 in — a validation limit on each paver face dimension, shared with the tile engine; not a material figure.
• Bedding depth default, 1 in — the form's starting value when the field is blank (shown as 2.54 cm in metric mode), a common screeding depth and nothing more; the engine has no opinion about base design.
• Coverage per paver — none. This page holds no product figure. The face area is computed from the dimensions you enter, and the joint between pavers is not part of it (see the FAQ on joints and the joint example below).

Worked examples

Every figure in this table was produced at build time by the paver engine from the inputs shown. "Net" is the pure division, "adjusted" applies the waste column, "buy" is the headline the result box would show, and "spare" is the fraction of a paver the round-up added. The metric row was entered as meters and centimeters and converted exactly before the engine ran, which is what the metric toggle does.

The walkway, in 4 × 8 in pavers. A 36 × 4 ft path is 144 sq ft. A rectangular paver has a smaller face than the 6 in square — 0.2222 sq ft, a repeating decimal the engine carries at full precision — so the division gives 648 pavers net. The 10% allowance makes that 712.8, which is not a whole number, so the round-up buys 713 pavers with 0.2 of a paver spare. The bedding at 1 in is 12 cu ft, 0.444 cu yd. Shape never enters the arithmetic: a long, narrow footprint and a square one of the same area produce the same count.

The large-format patio, 16 × 16 in. A 16 × 14 ft patio is 224 sq ft, and each paver covers 1.7778 sq ft — more than a square foot — so the net count is only 126. With waste that is 138.6, bought as 139 pavers, 0.4 spare. Here the bedding was entered at 1.5 in rather than the default: 28 cu ft, 1.037 cu yd — 1.5 times the volume the same footprint would need at 1 in, because the sand line is a straight multiple of the depth.

The L-shaped patio, entered as an area. Totalled on the square footage calculator at 255 sq ft and pasted into the area field, in 12 × 12 in pavers whose face is exactly 1 sq ft: the net count equals the area, 255 pavers; waste lifts it to 280.5; and the round-up buys 281 pavers with 0.5 spare. Bedding at 1 in is 21.25 cu ft, 0.787 cu yd. The length and width fields were left empty; had they held values as well, the area would still have won.

The worked patio with no allowance and no bedding. Set the waste field to 0 and the bedding depth to zero on the 12 × 10 ft patio and the engine returns the bare division: 480 net, 480 adjusted, 480 pavers, 0 spare, and no sand line at all. Compared with the 528 the default buys, the difference of 48 pavers is the allowance and nothing else — on this patio the geometry divides evenly, so the rounding contributes nothing in either case. Zero is a legitimate entry when your own take-off already carries a margin; it is a poor one for a bordered or diagonal layout, for reasons the waste guide works through.

The priced patio, 6 × 9 in. An 18 × 12 ft patio is 216 sq ft; each paver covers 0.375 sq ft, so 576 net, 633.6 with waste, and 634 pavers with 0.4 spare. This example also has a value in the price field: suppose you typed 2 into it as a stand-in for whatever your own supplier quoted — the site holds no paver price and suggests none — so the cost line reads 634 × 2 = 1,268, in the same currency you typed. It is computed on the rounded count because the rounded count is what you buy; change the price and only that last line moves. Bedding at 1 in: 18 cu ft, 0.667 cu yd.

The metric patio, 20 × 20 cm. In metric mode, a 4.5 × 3 m patio with 20 cm square pavers and 2.5 cm of bedding reaches the engine as 14.7638 × 9.8425 ft, 7.874 in faces, and 0.9843 in of sand — each conversion exact. The footprint is 13.5 m² (145.31 sq ft), each face 0.04 m² (0.4306 sq ft), and the division gives 337.5 pavers net, 371.25 with 10% waste, and 372 pavers to buy. The bedding is 0.338 m³, shown with 0.441 cu yd beside it. The counts are identical in either unit system; only the labels change.

The worked patio with the joint added. The engine counts pure face area, as the FAQ explains. If a layout uses a wider joint than a swept-sand gap and you want it counted, add the joint to each face dimension: entering the 6 in paver as 6.125 in square gives a face of 0.2605 sq ft instead of 0.25, a net count of 460.61 instead of 480, and a purchase of 507 pavers instead of 528. The difference of 21 pavers is the direction of the simplification: ignoring the joint buys slightly more, never less.

How to read the result

The headline line is the purchase decision: Buy N pavers. Beneath it, the Patio line shows the footprint that reached the engine and the division that produced the net count — the face area per paver and the fractional result — so a typo in a dimension or a paver size is visible before it is padded. With N% cutting waste shows the adjusted count with the percentage that produced it. Sand bedding at D in gives the layer's volume in cubic yards with cubic feet in brackets (cubic meters first in metric mode), and it disappears when the depth is zero. Estimated paver cost appears only when a price was entered. Read the patio line to check your geometry, the waste line to check your allowance, and the headline to place the order; the difference between the headline and the adjusted count is the spare the round-up added, always less than one paver. The copy button places a one-line plain-text summary on the clipboard.

Common misreadings

Paver size in feet. The paver fields take inches; the patio fields take feet. Enter the 6 in paver as 0.5 — its size in feet — and the engine sees a 0.5 × 0.5 in paver with a face of 0.0017 sq ft: the same 120 sq ft patio needs 69,120 pavers net and a purchase of 76,032 instead of 528 — 144 times the correct count, the square of the inches-per-foot factor, because the slip hits both face dimensions. The mirror-image slip, patio dimensions typed in inches, inflates the footprint by the same factor. If the count looks absurd, check which unit each field wants before anything else.

Metric figures in the imperial fields. The metric patio above is 4.5 × 3 m with 20 cm pavers and 2.5 cm of bedding. Type those same numbers with the toggle still on Imperial and the engine sees a 4.5 × 3 ft patio of 20 in pavers on 2.5 in of sand: 13.5 sq ft, 4.86 pavers net, a purchase of 6 pavers against the correct 372, and 0.104 cu yd of sand against 0.441. The error is not a simple factor, because the footprint shrank while the paver faces and the bedding grew; if the count looks implausibly small, check the toggle.

Waste as a fraction. The waste field takes a percentage. The walkway at 10% buys 713 pavers; typed as 0.1 it is read as 0.1%, the adjusted count falls to 648.65, and the purchase drops to 649 — 64 pavers short of the intended allowance, with no warning, because a fraction of a percent is a valid input.

A stale area. The total-area field overrides the length and width whenever it holds a value. Fill it for one patio, then change the dimensions for another, and the count will not move until the area field is cleared. The patio line in the result shows the footprint actually used, which is the quickest check.

Nominal names for measured faces. A product name describes a family, not a face: pavers sold under the same name vary by manufacturer, as the FAQ notes, and a small difference in each edge compounds in the division. The specification sheet's dimensions are the ones to enter.

Padding twice. Rounding the patio up before entering it, raising the count after the fact, and the waste percentage are the same margin applied in different places. The pipeline applies the allowance to the count and the round-up to the allowance, exactly once each; the no-allowance example shows what the geometry alone needs, and the waste percentage is meant to be the only other margin.

Where the model stops

The engine models one flat area covered edge to edge by identical rectangular pavers, counted by face area alone. It does not model the joint between pavers (the simplification errs toward buying enough, as the joint example shows); the pattern — it has no knowledge of herringbone, circles, or diagonal sets, or of which offcuts can be reused; or a border course in a different paver, which is a second run of the tool with the border's own area and face. Nothing is deducted from the area you enter. Waste is one flat percentage, which is why the waste guide exists. The sand line is the bedding layer only: it carries no allowance and no whole-yard rounding, it is not converted to weight, and it says nothing about the compacted base beneath it, which is a separate layer sized on the gravel calculator. Edge restraint, joint sand, compaction, delivery minimums, and the slope and drainage of the finished surface are outside the model, as subgrade preparation is for every estimator on the site. And, as the note under the form says, this page produces counts and volumes only — base thickness, drainage, slope, and anything load-bearing or permit-related are decisions for a qualified contractor or engineer, and the dimensions you enter should already carry that review. The methodology page lists the simplifications every estimator shares.

Under and around the patio

Order the screeding layer with the sand calculator and the compacted base with the gravel calculator — both take the same footprint at their own depths. Walls instead of floors? The brick and concrete block calculators run the vertical equivalents, and indoor tile follows the same face-area logic (plus grout) on the tile calculator. The square footage calculator settles an irregular footprint, the feet & inches calculator turns tape readings into decimal feet, and the construction unit converter moves any figure between square feet and square meters. For the reasoning behind the percentage, start with Waste factors, explained; How material estimates are calculated walks the five stages number by number, Metric and imperial in the estimators covers the unit toggle, and the rest are on the guides index.

Frequently asked questions

Nothing you type leaves your device. The estimating pipeline is documented on the methodology page.