How these tools are tested

Every tool on this site is checked against software written by somebody else. That is the only test worth running, because a tool that grades its own homework will always agree with itself about being wrong.

This page lists what is actually checked, by what, and what the current results are. It is deliberately specific. You should be able to reproduce any of it yourself.

QR codes

The QR encoder here was written from scratch rather than pulled from a library, which means it has to earn trust rather than borrow it. Two independent checks run against it.

First, the Reed-Solomon error correction is proved mathematically: the finished codeword polynomial is evaluated at each root of its generator, and every result must be zero. That is not a spot check against known output, it is the property the encoding is supposed to have.

Second, every symbol is compared module by module against libqrencode, the reference implementation most of the world uses, and then the rendered image is read back by zbar, a real scanner. Across 13 payloads at all four error correction levels, 52 of 52 symbols currently scan and 39 are identical to the reference. The other 13 carry a different mask pattern that scores better under the specification's own rules, which the specification permits.

Two bugs were caught this way that no amount of reading the code would have found. The format bits were written in reverse order, which left all 625 data modules correct and the symbol completely unreadable, because the format is what tells a scanner which mask was used. And the second copy of the format information sits seven modules up the column and eight along the row rather than eight and seven, where the eighth position in the column is the fixed dark module, so writing it in the wrong place changed nothing visible.

Barcodes

EAN-13, UPC-A, EAN-8 and Code 128 are verified the same way: 16 rendered symbols are read back by zbar, including the published reference codes 5901234123457 and 9780201379624, which have known correct values. A generated barcode that a scanner cannot read is not a barcode, so scanning is the only test that counts.

PDFs

Files produced by the merge, split, rotate, image to PDF and compress tools are opened by qpdf and poppler, neither of which has any connection to the library that wrote them. Between them they confirm the page count, the page sizes, the page order, that text is still selectable text rather than a picture of text, and that a rotation was genuinely recorded in the file rather than only shown on screen.

For the compressor specifically, qpdf must report no syntax or stream errors in the output, poppler must confirm the page is still A4, and pdftoppm must be able to render it back to an image.

Hashes

Every hash is checked against OpenSSL, through Node's own crypto module. MD5 is written out by hand here, because no browser will ever expose it: the Web Crypto API deliberately refuses to hand out a broken hash as a primitive. A hand-written MD5 is exactly the kind of code that is subtly wrong, so the test includes both block boundary cases, at 55 and 56 bytes, where padding behaviour changes.

ZIP files and favicons

The ZIP writer is about seventy lines and produces the archives you get from the split and favicon tools. It is checked by a real unzip, and that test found a genuine bug: the central directory size was being measured after the record had already been written, which unzip read as a possible zip bomb.

For the favicon generator, the ZIP the browser produced is opened by unzip and every frame inside the .ico is read by ImageMagick, which reports PNG 16x16, 32x32 and 48x48. A favicon file that claims three sizes and contains one would look fine until it did not.

Images

Canvas encoding cannot be tested outside a browser, so the image tools are checked in one instead. A real PNG with a transparent region is put on the file input by the test harness, the download is captured, and the bytes on disk are inspected: the pixel dimensions are read straight out of the PNG IHDR chunk and the WebP VP8 headers, not taken from anything the page says about itself. ImageMagick was used once to confirm that reader agrees with it.

Calculators

Financial maths is checked against published figures rather than against itself. A SIP of 5,000 a month at 12 percent for ten years returns 11,61,695, which is the number the fund houses publish, and that exact figure is asserted in the test suite. The EMI amortisation is checked so that the principal and interest columns sum back to the instalment and the closing balance reaches zero in the final month.

The pages themselves

Before anything can be deployed, the whole site is driven by a real browser over the Chrome DevTools Protocol: files are put on file inputs, buttons are clicked, downloads are caught and parsed. Alongside that, a static pass checks that every published tool is linked from every page before any JavaScript runs, that no script is fetched without a cache-busting version, that no control on any page is greyed out rather than hidden, and that the controls in every row of every form share a bottom edge within three pixels, because an unaligned checkbox was reported three separate times before it was fixed properly.

What this does not mean

None of this makes the tools perfect. It means the specific things listed above are checked by software that has no reason to agree. Where a tool cannot do something, the page says so plainly instead of quietly doing it badly: the compressor hands back your untouched original when compressing would have made the file larger, the JWT decoder refuses to verify signatures rather than asking you for a production secret, and the YAML converter names the constructs it will not handle rather than silently dropping them.

If you find something wrong, the contact page is real and so is the address on it.