We tested 39 online calculators on four arithmetic traps

What we set out to find

Four calculations trip people up so reliably that each one has a name. Margin gets confused with markup. Two discounts get added instead of compounded. A length divided by a spacing gets reported as a number of posts. A payment fee gets multiplied on top of the amount you wanted to keep, when it should be divided out of the amount you charge.

We build calculators, and we hit all four while building ours. The obvious question was whether the tools that rank for these searches make the same mistakes, so we tested them. The result isn't the one we expected, and we're publishing it as it came out.

Of 39 live calculators we could drive to a readable answer, across 24 domains, 38 returned arithmetic we agree with and one did not. The one failure is a wrong label attached to a right formula, which produces a wrong number for anyone who reads the label. That turns out to be the shape of the risk in this category. The formulas hold up. The labels are where the money leaks, and the confusion lives in the user's head. The code is fine.

How we tested

Testing date: August 17, 2026. Everything below was captured that day.

• Each tool was loaded in headless Chrome 151 and driven through the DevTools Protocol. Values went in as real keyboard events instead of being written to the DOM, because several of these calculators are built in React and ignore a value written straight into the field.
• Every tool in a group got the same input. Where a tool's fields are shaped differently, profit and revenue instead of cost and revenue, we entered the same scenario through the fields it offers and say so in the row.
• The output recorded is the text the page displayed, copied verbatim. Where a value couldn't be captured cleanly (a consent overlay, a button that does nothing in headless mode), the tool is listed as not captured and is not counted either way.
• We didn't use search engines to find the tools, because search result pages serve CAPTCHAs to automated browsers. Candidates came from known domains in the category and from those sites' calculator index pages.

Four tools are left out of every count because we couldn't read a result from them. calculator.io's margin calculator produced no output from its Calculate button in headless Chrome. calculatored.com's profit-margin URL redirects to its homepage, so that site has no margin row, though its discount calculator works and is tested below. easycalculation.com didn't respond at all. And miniwebtool's net-profit-margin calculator displayed the correct formula with our numbers in it, Net Profit ÷ Revenue × 100, with 40.00 and 140.00, but a consent overlay covered the final figure on every attempt, so we aren't scoring it.

Trap 1: margin is not markup

Input for every tool: an item that costs 100 and sells for 140. The profit is 40. As a share of the selling price that's a margin of 28.57%. As a share of the cost it's a markup of 40%. A tool that reports 40% and calls it margin is wrong. A tool that reports 40% and calls it markup is right.

The prepostseo failure deserves a precise description, because the formula itself is fine. On page load the mode selector reads Gross Margin, but the two input boxes carry the labels of a different mode: Total Sale and Net Profit (After Taxes). The arithmetic that runs is gross margin, so box one is treated as cost and box two as revenue. We confirmed both halves. Entering 100 and 140 into those same two boxes returns Margin 28.5714%, Profit $40.00, Markup 40: correct for cost and revenue, and impossible for a sale of 100 with a profit of 140. Touching the dropdown fixes the labels to Cost and Revenue. Anyone who trusts the page as it loads gets a negative margin on a profitable product.

Six of these tools also take a target margin and solve for price. We gave all six a cost of 100 and a desired margin of 40%, where the right answer is 166.67 and the tempting wrong one is 140. All six returned 166.67: calculator.net, calculatorsoup.com, gigacalculator.com, omnicalculator.com, thecalculatorsite.com and inchcalculator.com. CalculatorSoup shows the rearrangement on screen.

Trap 2: two discounts do not add

Input for every tool: a price of 100, discounted 30%, then a further 20% off the discounted price. The right answer is 56, a total of 44% off. The wrong answer is 50, from adding 30 and 20.

Eight of the fourteen take a second discount, and all eight compounded it. The six that handle one discount all returned $70.00, which is the right answer to the question they actually ask.

Two things here need saying out loud. calculatored.com and calculator-online.net return byte-similar output from what is evidently the same engine on two domains, so they aren't two independent implementations and shouldn't be read as two independent confirmations. And prepostseo.com, the one site with a wrong margin calculator, has a discount calculator that behaves correctly. One broken page doesn't make a broken publisher, and the row above says so.

The single-discount tools are where fairness gets tested. calculator.net's discount calculator does one discount and says so, and its own copy sends the reader elsewhere for the stacked case: "such as stackable discounts where you can get 20% off the original price, then 15% more off of that discounted price. If you need to do these kinds of calculations, refer to the Percent Off Calculator." That's a tool doing its job and warning about the trap, so we didn't score it as a failure. Six of the tools in this group carry a warning like that. Miniwebtool states flatly that "20% off + 10% off does NOT equal 30% off", calculatored prints "the effective discount is 44%, not 50%" in the result itself, and inchcalculator answers "What is a stackable discount?" by telling you to iterate. This is the one group where the tools actively teach the trap instead of just avoiding it.

Three pages we opened aren't discount calculators, so we excluded them instead of scoring them. percentagecalculator.net and percentage-off-calculator.com offer only generic "what is X% of Y" widgets that never produce a final price, and thecalculator.co's discount URL returns HTTP 200 while serving a page titled "Emotional Abuse Test".

Trap 3: posts are not gaps

Input for every tool: a straight, open run of 120 feet with posts every 8 feet. That's 15 sections and 16 posts, because a straight run has a post at each end. Returning 15 is the classic off-by-one. The exception matters: on a closed perimeter the last post is the first one, so 15 would be correct there. That's why a tool that lets you say which shape you're building can't be judged on the number alone.

Every fence calculator we could drive got the +1 right, and three of the five spell it out in their own copy. inchcalculator writes "(length in ft. ÷ 8′) + 1 = posts", omnicalculator prints the formula, and calculator.academy has a dedicated question explaining why an open run needs one more post than a closed perimeter. blocklayer doesn't say it in prose but exposes corner options ("No Corners", "1 End Corner", "Both End Corners"), which is the same idea made selectable. spikevm applies the +1 without naming it. This was the trap we most expected to catch someone on, and nobody fell into it.

Two caveats we owe you. Omni Calculator was measured in metric (30 m at 3 m spacing, where the right answer is 11 posts over 10 sections) because its unit dropdowns are custom widgets that wouldn't accept a scripted change; the arithmetic under test is identical. And blocklayer.com only renders under a real desktop user-agent. With the headless string it returns a network error, so we set one before testing it.

calculator-online.net is the odd row. Its own copy states the correct formula, "Number of Posts = (Fence Length / Post Spacing) + 1", but the live tool never outputs a post count, and the section figure it does print didn't change when we changed the inputs. That's a broken tool, a different problem from an off-by-one, and since we can't show a wrong post count we don't claim one. We also couldn't test hooverfence.com, which sits behind a Cloudflare challenge, or jacksons-fencing.co.uk, which sells panel packages instead of taking a run and a spacing.

Trap 4: the gross-up is a division

Input for every tool: Stripe's US card rate of 2.9% + $0.30, and a target of receiving exactly $1,000.00 net. The amount to charge is (1000 + 0.30) ÷ (1 − 0.029) = $1,030.18. The tempting wrong answer is 1000 × 1.029 + 0.30 = $1,029.30, which actually nets $999.15. We also ran the forward case: charge $100.00, fee $3.20, net $96.80.

Six of the eight offer a gross-up mode, and all six invert the fee properly instead of adding it on top. Two do only the forward calculation and say so, which makes them incomplete and still correct. We also ran ebayfeescalculator's UK page, which uses its own published rate of 1.5% + £0.20 and returned £1015.43 where the true inverse gives £1015.4315. So the engine behind it does the real division, and the US case isn't hard-coded.

Two things about this group are worth recording even though they aren't errors. listingprep's reverse tab ships with its "item cost" field pre-filled at $3.00, which makes the answer look three dollars wrong until you notice the field and zero it. Nothing is broken there, but that default will be misread. And a large share of the domains that once hosted payment-fee calculators are simply gone. stripefeecalculator.com and its .app, .net and .io variants have no DNS record, omnicalculator has no Stripe page at all (only PayPal), and paypal-fee-calculator.com now returns HTTP 200 serving a Turkish casino affiliate site. We name that last one so nobody links to it. feecalc.io was reached but excluded: its on-page widget is a teaser for a browser extension, with no Stripe schedule and no gross-up mode, so there was no comparable test to run.

The arithmetic, written out

So that anyone who disagrees has something concrete to argue with, here is every claim above written as a calculation.

Margin and markup

Profit is 140 − 100 = 40. Margin divides profit by the price you charge: 40 ÷ 140 = 0.2857, so 28.57%. Markup divides the same profit by the cost you paid: 40 ÷ 100 = 0.40, so 40%. Same profit, different denominator. Going the other way, a target margin m on cost c needs a price of c ÷ (1 − m), because the margin is a share of the price and the price is the unknown: 100 ÷ (1 − 0.40) = 100 ÷ 0.60 = 166.67. Charge 100 × 1.40 = 140 instead and the margin comes out at 40 ÷ 140 = 28.6%. That gap quietly eats a business.

Stacked discounts

Discounts multiply what remains. They don't add up what comes off. 100 × 0.70 = 70; 70 × 0.80 = 56. The total taken off is 44, so the effective discount is 44%, not 50%. As one step: 1 − (0.70 × 0.80) = 0.44.

Posts along a run

120 ÷ 8 = 15, and 15 is the number of gaps. A straight run has a post at both ends, so posts = gaps + 1 = 16. A closed perimeter has no free ends, so posts = gaps = 15. The same +1 governs joists, studs, balusters, rebar and anything else that sits at the edges of the spans instead of inside them.

Fee gross-up

The percentage fee is charged on the amount you charge, not on the amount you wanted to keep, so the amount you charge is the unknown and belongs in the denominator. If x is charged, you keep x − (0.029x + 0.30). Set that equal to 1000 and you get x(1 − 0.029) = 1000 + 0.30, so x = 1000.30 ÷ 0.971 = 1030.18. Multiply instead, 1000 × 1.029 + 0.30 = 1029.30, and after the same fee schedule you're left with 1029.30 − 30.15 = 999.15: eighty-five cents short, on every transaction, forever.

What we did not count as an error

This section is where research and accusation part ways.

• An incomplete tool isn't a wrong tool. One that computes one discount and says it computes one discount is fine. So is a fee calculator without a gross-up mode, or a margin calculator that doesn't also print markup. Missing a feature and returning a false number are different failures, and only the second one costs the reader money.
• A different fee schedule isn't an error either. Payment calculators quote different rates by country and card type. Where a tool used its own published rate, we recomputed the correct answer under that rate before judging it.
• Rounding choices don't count. ebayfeescalculator.com returns $1030.17 where we compute $1030.18, because it truncates the cent instead of rounding up. Under real cent-rounding, charging $1030.17 still nets exactly $1,000.00, so the answer is right. We flag it as a rounding choice, and note that the same truncation costs a cent on a $100 gross-up.
• A tool we couldn't drive isn't a failure. Four tools wouldn't give up a readable result under automation. That's our constraint and says nothing about their arithmetic, so they are excluded from the counts entirely instead of counted as failures.
• Ambiguity isn't error. Where a tool gives no way to say whether a run is open or closed, a post count that matches the number of gaps is ambiguous, and we labeled it ambiguous.

What this actually shows

We went looking for broken calculators and mostly didn't find them. The arithmetic in this category is in better shape than its reputation: the large, well-linked tools compute margin, markup, stacked discounts and fee inversions correctly, and several of them explain the trap in their own copy before it can bite the reader.

What we did find is that the danger has moved. The one failure in 39 is a labeling defect, the right formula behind the wrong words, and labeling is exactly where the remaining risk in this category sits. Nothing in a calculator's output tells you whether the number you're looking at is a share of cost or a share of price. If the page names it wrong, or you read the field you expected instead of the field that's there, the tool has no way to catch you. The division is the easy part. The most useful thing a margin calculator does is print both numbers side by side, so the difference is impossible to miss. Before you set a price from any of these tools, check which of the two you're reading.

Corrections and re-testing

Every result on this page is a snapshot of August 17, 2026. Any of these sites may have changed since, and we'd count a fix as a good outcome. If the prepostseo labels have been repaired by the time you read this, that's the point of publishing. We will rerun the full set and date the update instead of quietly editing a row.

If you think a row is wrong, a useful report has the URL, the exact values you entered, the output you got and the output you expected. That's the standard we held ourselves to above, and it's the only kind of correction we can act on.