My calculators gave correct answers to the wrong questions, so I started asking back

When I tested my calculators the way people actually type, the first problems I found were not about wrong maths. The maths was right. The input was a different number from the one the person meant, and the page answered that number with full confidence. I made these tools, and this is what I changed so they ask back instead: https://instantfreetools.com/compound-interest-calculator/ A 5% rate typed as 0.05 Interest rates show up in two forms. Banks print "5%", and spreadsheets and finance classes write the same rate as 0.05. My compound interest field expects percent, so 0.05 means 0.05%. The gap is large. $10,000 for 10 years at 5% compounded monthly grows to $16,470.09. At 0.05% it grows to $10,050.12. Both results are correct for what was typed. Only one of them is what the person wanted. The tempting fix is to multiply anything below 1 by 100. I didn't do that, because a 0.5% savings rate is real, and silently turning it into 50% would be worse than the original problem. So the page keeps using the number as typed and asks: export const decimalRate = (r) => (r > 0 && r < 1 ? Math.round(r * 1e8) / 1e6 : null); If the rate is above 0 and below 1, a line appears under the result: "Using 0.05%. Did you mean 5%?" with a button that puts 5 in the field. For 0.5 it asks about 50%, and the person can ignore it. For 5 it says nothing. The rounding is there because 0.07 * 100 in floating point is not exactly 7, and I don't want to show "7.000000000000001%" in a question. One bug came from the button itself. The hint redraws on every change of the field, and clicking the button changes the field. The first version rebuilt the hint while the click was still happening, so the button vanished before the click registered. Now the hint only redraws when the suggested value is different from the one already shown. Height in metres in a centimetres box The BMI calculator has a height field labelled cm. In testing I typed 1.75, the way many people write their height. With 70 kg that gives 70 ÷ 0.0175², which is a BMI of 228,571.4, and the page showed it next to a category name. Here a silent fix is safe, because no adult is 1.75 cm tall. Any value between 0 and 3 in the cm box is read as metres: export const readCm = (v) => (v > 0 && v < 3 ? { cm: Math.round(v * 1000) / 10, meters: true } : { cm: v, meters: false }); The result then says "Read 1.75 as 175 cm.", so the conversion is not hidden. With 70 kg that comes to 22.9, Healthy weight. The second part of the fix was a plausibility check. Height has to be between 50 and 272 cm and weight between 2 and 650 kg. Outside that range the page shows no BMI and asks the person to check the numbers. A wrong-but-plausible number is still possible, but an absurd one no longer gets a label. The rule I ended up with: if a misreading is impossible, convert it and say so. If it is possible, keep the input and ask. Commas, dots and currency symbols The percentage calculator gets pasted input, and pasted numbers are messy. People paste "$80", "12.5%", "1,250", and from much of Europe, "12,5" meaning twelve and a half. A plain Number() rejects most of these, and parseFloat("1,250") returns 1. The parser strips spaces, the percent sign and common currency symbols, then decides what a comma means: "1,250" has exactly three digits after the comma, so it is a thousands separator: 1250. "12,5" and "1,25" do not, so the comma is a decimal point: 12.5 and 1.25. "1.250,5" is the European full form: 1250.5. This is a guess, and it can be wrong. "1,250" written by a German user meaning 1.25 will be read as 1250. I kept the US reading because the site is in English, and the working line under each result shows the number that was used ("12.5% × 80 = 10"), so a misread is visible right away. Floating point in the output 0.1 + 0.2 is 0.30000000000000004 in JavaScript, and people do type 0.1 and 0.2. Every percentage result goes through one function before display: export const tidy = (x) => (x === null ? null : Number.parseFloat(x.toPrecision(12))); Twelve significant digits keeps every realistic result exact and removes the binary noise, so the answer shows 0.3. The same page has a worked example that surprises people more than any bug: add 10% to 100 and you get 110, then take 10% off and you get 99, not 100. That one is correct, and the calculator shows both steps so it doesn't look like an error. What changed in how I build these Every input field has a "what if they type the other unit" test. For rates that is 0.05 against 5. For height it is 1.75 against 175. Converting silently is only allowed when the other reading is physically impossible. Otherwise the page asks. The page shows the number it actually used, next to the result. It costs one line and it catches mistakes the hint logic never thought of. The hint has to survive being clicked. It sounds obvious, but my first version failed it. None of this is clever code. Most of it came from testing the inputs people are likely to type. If you have run into a version of this problem in your own forms, such as dates, phone numbers or units, I'd like to hear how you handled it.