How we check our tools

Exact math with no rounding

Ordinary JavaScript numbers lose precision above 2⁵³, which is why many online converters get large values wrong. Our number tools use whole-number arithmetic with no size limit instead. FFFFFFFFFFFFFFFF converts to exactly 18446744073709551615, and a 200-digit binary number converts without losing a digit.

Fractions are the one place where a result can be cut short. Some fractions never end in another base (0.1 in decimal repeats forever in binary), so the tool stops after 32 digits and says so on screen instead of hiding it.

Test cases before a tool goes live

Each tool runs through a fixed set of cases in a real browser before it is published. The set covers typical values, edge values such as 0, 255, 256 and the largest 64-bit number, negative numbers, empty input, very long input and invalid input like a 2 in binary or a G in hex. A few cases from the current set:

• 11110110 read as signed binary gives -10.
• -10 written as 16-bit two's complement gives 1111111111110110.
• 300 at a width of 8 bits is rejected with a message, because the largest 8-bit value is 255.
• 101101 divided by 101 gives 1001 with remainder 0, and the long division table shows each step.

The expected answers are worked out separately, by hand or with a programming language's built-in conversion functions, and compared with what the tool shows. When a tool changes, the whole set runs again, so a fix in one place cannot quietly break another.

Text and character encodings

Text tools are tested with plain English, accented letters, Cyrillic, Chinese and emoji, in UTF-8 and in older encodings such as Windows-1252. Each test string goes from text to binary and back again, and the round trip has to return the same text byte for byte.

Examples on every page are checked in the tool

Worked examples, tables and diagrams on the tool pages come from the same numbers the tool produces. Every example can be pasted into the converter on that page to get the same answer. If a page and its tool ever disagree, that counts as a bug.

Standards we follow

• ASCII for codes 0 to 127, as described in RFC 20.
• UTF-8 as defined in RFC 3629.
• Legacy character sets as mapped in the WHATWG Encoding Standard, the same tables web browsers use. Codes 128 to 255 in the ASCII table follow Windows-1252.
• Two's complement for signed integers, the format used by almost every processor today.

Who does the checking

Our QA testers check every tool before release. Sophiko Gorgadze runs functional and regression tests, Tomeshia Brock tests each tool on iPhone, Android and desktop browsers, and Sharmina Rahman runs automated and accessibility checks. The tester who checked a tool is named in the strip under it.

What the strip under each tool means

• Checked by names the tester who ran the tool through its test cases.
• Reviewed by names the subject expert who read the explanation and the worked examples on that page.
• Last updated shows the date the tool or the page text last changed.

How the guides are checked

Code in the guides is run before publishing, and the output shown under each block is copied from that run. Facts about a standard are checked against the standard itself, such as RFC 3629 for UTF-8 or the Python documentation for struct. A reviewer then reads the guide and is named at the top of it with the writer.

Your data stays in your browser

All conversions run on your own device. Nothing you type or open is uploaded, so a test file or a private value never reaches our server. The privacy policy covers this in full.

When something is wrong

Mistakes still happen. If you get a result you think is wrong, email [email protected] with the input, the tool page and the answer you expected. A Share link from the tool carries all three. Each report is reproduced first. If the tool or the page is at fault, it is fixed, the case is added to the test set so the same bug cannot come back, and the full set runs again before the change goes live.