How Accurate Are RedBison's Tools? 7,331 Tests That Check the Answers

The 7,331 automated tests that check our tools' answers, where the expected values come from, bugs they caught, the limits no test removes, and how to report a mistake.

November 2, 2026 · 11 min read

If you use a mortgage calculator, a unit converter or a hash generator, you are trusting it to be right. Most of the time you have no way to check, which is the reason you used the tool in the first place. So it is fair to ask how accurate RedBison's tools are, and how we know.

The short answer: every tool's calculation code is tested against values that someone else published, such as standards bodies, RFCs, textbooks and established software, and the tests run before every release. As of November 2026, 7,331 automated tests check that our tools give the right answers, and all of them pass. 2,516 of them were added this month to test the edges: zero, empty and enormous inputs, values exactly on a threshold, and input that is simply wrong. This post explains what those tests cover, the bugs they have caught, what no test can promise, and how to tell us when something looks wrong.

7,331 tests that check the answers

Each of these tests feeds a known input into the same code the tool page runs and compares the output with an expected answer. Here is how they spread across the catalog, with the tests we already had and the edge-case tests added this month.

• 1,820 tests for everyday, finance, health and maths calculators: loans and mortgages, savings, pay and tax, body measurements, pregnancy dates, statistics, geometry and unit maths.
• 1,742 tests for developer, text and security tools: formatters, encoders, hashes, certificates, keys, JWTs, cron, SQL, GraphQL, network and data format tools.
• 1,177 tests for the answers AI assistants get. Many calculators can be used from Claude, Cursor and other assistants through our MCP server. They share their code with the pages, and these tests make sure the assistant gets the same answer you would see on the site.
• 976 tests for AI tools: token counts, cost estimates, GPU memory sizing, dataset checks and the configs and code the generators write.
• 889 tests for engineering calculators: beams, columns, electrical sizing, fluids, HVAC, carpentry, sheet metal and more.
• 727 tests for file, image and media converters: PDFs, documents, spreadsheets, archives, photos and video.

Testing the edges, not just the typical case

Most bugs do not show up on the input a tool was designed around. They hide at the edges: a 0% interest rate, a one-row spreadsheet, a value exactly on a code limit, a date that does not exist, a file cut off halfway. So this month we went through the calculation code of every tool and, for each function, wrote four kinds of test:

• Positive: a typical input with an answer taken from a published source.
• Edge: the limits of what is valid, such as zero, one, empty, the largest allowed value, leap days and exact thresholds where "less than" and "less than or equal" give different answers.
• Corner: edges combined, such as a zero rate over a long term, emoji and right-to-left text, Windows line endings, or very large and very small numbers in the same calculation.
• Negative: input that is simply wrong, such as negative lengths, impossible dates, broken JSON or a damaged file. The tool must say what is wrong. It must never freeze, crash or show a believable but wrong number.

To find the gaps we measured which decisions in the code (each if, each fallback) the tests actually exercised. At the start of the month the tests reached 74.6% of them. They now reach 90.6%. The remainder is mostly code that only runs in a browser, such as image decoding and video encoding, which is checked by the converter tests and by hand.

We also added a sweep that pushes every calculator to the limits of every one of its inputs, from the smallest value it accepts to the largest, and every option. A calculator may refuse an input with a clear message. It may not crash or hang. On its first run the sweep found two tools that did, and a third that quietly fell back to a less accurate method.

As before, the expected answers come from outside the code under test: standards, RFCs, published tables, established software such as OpenSSL, Python and the TypeScript compiler, or a hand calculation written out next to the test.

Where the expected answers come from

A test is only as good as the answer it expects. If we wrote a calculator, ran it once and saved its output as the "right" answer, the test would protect a bug instead of catching it. So wherever possible the expected values come from outside RedBison. Some real examples from the suite:

• Statistics. The Linear Regression Calculator reproduces the certified values for the NIST Statistical Reference Datasets, including the Norris data set, and the standard deviation code matches NIST's NumAcc tests, which are designed to break naive formulas with large, nearly equal numbers. Chi-square tail probabilities are compared with SciPy and with textbook critical values.
• Hashing and security. The Hash Generator must produce the same MD5, SHA-1, SHA-256 and SHA-512 digests as the standard command-line tools. The JWK tool must compute the exact key thumbprint printed in section 3.1 of RFC 7638.
• Engineering. The Beam Deflection Calculator is checked against worked examples, such as a 20 ft steel beam under 1 kip/ft deflecting 0.155 in. The Air Changes Calculator must return 68.25 cfm for the ASHRAE 62.2 example of a 1,525 sq ft home with two bedrooms.
• Dates. Week numbers follow ISO 8601, including years with 53 weeks, and every day from 2020 to 2030 is round-tripped through the ISO week date. US-style week numbers match Python's strftime reference output.
• Money. The Mortgage Calculator matches published mortgage payment tables, a 30-year loan at 6% must pay down to exactly zero with the textbook total interest, and the final payment must never overpay, which is where rounding errors usually collect.

When a tool relies on a well-known format such as UUIDs, CSV, YAML, cron expressions, QR codes or Protocol Buffers, it uses an established, widely tested library instead of a parser we wrote ourselves. That removes a whole class of edge-case bugs before they start.

Bugs we found, and the tests that keep them fixed

Tests do not make software perfect. They make each mistake happen once. When we find a bug, the rule is to write a test that reproduces it first, watch that test fail, then fix the code. The test stays in the suite, so the same bug cannot quietly return. A few that we caught this way:

• The Protobuf Tools validator used to report every schema as valid. It now reports unresolved types and syntax errors, and a test feeds it broken schemas to prove it.
• The JWK tool once produced placeholder PEM text instead of a real conversion. It now converts RSA, EC and Ed25519 keys in both directions, and the tests round-trip each one.
• The Hash Comparison tool showed output labelled as Whirlpool and BLAKE2 that was not those algorithms, and treated Keccak as SHA-3. A test now makes sure it never presents one algorithm's output under another's name.
• The SQL Injection Tester gave its own built-in example a perfect score even though the example contained template interpolation, which is exactly the risk the tool exists to find. That pattern is now flagged.
• The Contrast Checker could round a ratio of 4.4999:1 up to 4.5:1 and report a pass for text that actually fails WCAG. It no longer rounds before comparing.
• The Advanced Calculator now shows 0.1 + 0.2 as 0.3 instead of exposing floating-point noise, without rounding tiny genuine results down to zero.
• The Date Difference tool counts the day the clocks go forward as one full day, not 23 hours.

What the edge-case tests found this month

The new tests found more than 150 bugs, and each was fixed in the same change as its test. To be sure the bugs were real and the fixes were needed, we ran the new tests against the code as it was before the fixes. 194 of them failed, and four more test files could not even finish, because the old code froze or ran out of memory. All of them pass now. Most of the bugs were in rare inputs, but some could have given a real answer that was wrong. A selection:

• The Wire Size Calculator could pick 14 AWG copper for a 16 A load. The National Electrical Code caps the breaker on 14 AWG at 15 A, so that wire cannot be used for the load however much current it can carry. It now picks 12 AWG.
• The Distance Between Coordinates calculator fell back to a less accurate spherical formula for any two points either side of the 180° meridian, such as Fiji and Samoa, because it measured the longitude gap the long way round.
• The Archive Converter did not check the CRC-32 checksum inside ZIP and gzip files, so a damaged file could extract as silently wrong bytes. Damaged files are now reported as damaged.
• Word to PDF and the other document-to-PDF converters dropped line breaks inside a paragraph, joining "one" and "two" on separate lines into "onetwo".
• The Invoice Generator printed a "
  quot; sign on a euro invoice when the locale code was written with an underscore, such as de_DE.
• The Paint Calculator froze when given an enormous room, because it tried every possible number of 5-gallon buckets one by one.
• The Database Seed Generator could write foreign keys pointing at rows that did not exist, and decimals too large for the column, so the generated data failed to load.
• The SQL EXPLAIN Visualizer reported an inner index scan as "off by 1000x" because it compared a per-loop row estimate with a total. PostgreSQL reports both per loop.
• The Pulley and Belt Calculator returned blank results for a belt too short to fit around the pulleys. It now says the geometry is impossible and why.

We list these because a tool site that claims it has never had a bug is not being straight with you. What matters is how bugs are handled once they are found.

What tests cannot promise

Accurate code is one part of a correct answer. The rest depends on the method and on your inputs, so a few honest limits:

• Calculators use stated methods. A body fat estimate, a concrete quantity or a cable size comes from a specific formula or table, and each tool page says which one. A different method, code edition or local rule can give a different answer.
• Estimates are not professional advice. Health, finance and engineering calculators are for planning and checking. A structural design, a tax return or a medical decision needs a qualified person who knows your situation.
• Converters depend on the file. A PDF built from scanned images, an unusual video codec or a damaged spreadsheet can convert imperfectly even when the converter is working as designed.
• Floating-point arithmetic has limits. Very large or very small numbers can lose precision in any software, including ours. Where it matters, tools work around it, and the tests check the hard cases: resistor colour codes give fractional ohms without stray digits, and probability functions keep their precision far into the tails.

How we keep improving

The test suite is never finished. Each new tool arrives with tests for its logic before it ships. Each bug report becomes a new test case. When we add support for a new standard or code edition, we add its published examples to the suite. We also measure which parts of the code the tests reach and add edge, corner and invalid-input tests where they do not, as we did this month, and the sweep of every calculator's input limits runs with the rest of the suite.

Every page also shows when its own content last changed. The "Updated" date on a tool or guide moves when that page's write-up or its page changes, not when the site is rebuilt, so you can see how recently a page was revised. A fix in calculation code shared by several tools does not move the date on its own.

Found a bug? Tell us

If a tool gives you an answer that looks wrong, a conversion that breaks, or a guide with an error, please email team@redbison.dev. You can also use the feedback icon in the footer of any page.

A useful report includes:

1. The page, for example the link to the tool.
2. What you entered, including units and any options you chose. Leave out anything private.
3. What you got, and what you expected. If you know where the expected value comes from, such as a textbook, a standard or another tool, tell us that too.
4. Your browser and device, if the problem is a page that will not load or a file that will not convert.

We read every report. When we confirm a bug, we write a test that reproduces it, fix the code, and ship the fix with the test, so the same mistake does not come back. You can read more about how tools are built and checked on our About page.

Browse all tools