Mortar joint volume calculator

The same pure function powers the free browser tool and the paid API, so a phone estimate matches the line item a quoting script posts later. Non-positive dimensions, a non-positive joint width, or a negative unit count fail with a clear invalid_input message instead of a silent nonsense volume.

How joint mortar volume is computed from unit size and joint width

Start from the geometry every masonry estimator uses when the unit size and joint thickness are known but a pre-tabulated mortar-per-brick figure is not. Attribute one bed joint and one head joint share to each unit. The bed joint share is the course length of the unit plus one joint width, times the unit depth into the wall, times the joint thickness. The head joint share is the unit face height times the same depth times the joint thickness. Zero units is allowed and yields zero mortar volume, which is useful for empty placeholder rows in multi-run schedules. This model covers single-wythe bed and head joints only; it does not add collar-joint volume between wythes, does not fill frogs or cores, and does not convert bagged mix mass—those are separate product intents. Adding those two contributions is algebraically identical to the compact product mortar_per_unit equals unit_depth times joint_width times the sum of unit_length, unit_height and joint_width, which counts the small joint-intersection prism only once. Multiply by the unit count to obtain mortar_volume_net. When waste_percent is greater than zero, scale the net volume by one plus waste_percent over one hundred so mortar_volume includes intentional overage for droppage, uneven beds, and cutting. When waste_percent is omitted or zero, net and total volume match. The pipeline is deterministic floating-point arithmetic with no random seeds, no wall-clock timestamps, and no network calls, so identical inputs always produce identical JSON. Unit dimensions and joint_width must be strictly positive because a zero-thickness joint or a zero-size brick is non-physical for a fill estimate. Unit count must not be negative: a negative brick or block count is rejected with invalid_input.

What you send and what you get back

Another useful check is one thousand blocks at two hundred by one hundred by four hundred millimetres with a ten millimetre joint and ten percent waste, keeping all linear inputs in millimetres so volume is in cubic millimetres, or converting everything to metres first for cubic metres. Send five required finite numbers: unit_length for the face length of one brick or block along the course, unit_height for the face height, unit_depth for the depth of the unit into the wall, joint_width for the mortar joint thickness, and units for the brick or block count. Optionally send waste_percent as a non-negative overage percent and precision as an integer from zero to fifteen for decimal places in the response. Missing required fields, non-numeric strings, NaN, and Infinity fail with invalid_input and are not charged. When any linear dimension or joint_width is zero or negative the request fails with a message that the field must be positive, so clients can correct dimensions before retrying. When units is negative the request fails with a message that the unit count cannot be negative. On success the response echoes cleaned inputs, mortar_per_unit, mortar_volume_net, waste_volume, mortar_volume, the precision used, a unit_note reminder to keep one linear system, the method label bed_and_head_joint_per_unit, and a short formula string for documentation. Classic checks include five hundred modular units at length zero point one nine, height zero point zero five seven, depth zero point zero nine and joint width zero point zero one with default waste: mortar_per_unit is zero point zero zero zero two three one three cubic units and total mortar volume is zero point one one five six five cubic units. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance.

Where a mortar joint volume calculator earns its keep

Masonry and hardscape crews building purchase schedules from takeoffs that list unit size, joint specification and count need a deterministic endpoint that separates net joint fill from optional waste so overstock stays intentional and auditable. Design studios specifying ten-millimetre versus twelve-millimetre joints can re-run the same unit count with a new joint_width and see how fill volume moves without reopening a spreadsheet full of fragile cell formulas. Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.