How we test

What tested means here

A tool on this site is called tested when a machine, not a person, has run it on real files and checked the result before the change went live. Every change to the code runs the whole suite, and a failing check blocks the release. The files people drop here are their own and often sensitive; a tool that breaks a contract or a scan has done harm.

Testing does not make a tool perfect, it makes its failures known. This page says what is checked, how, and what is not checked yet, so you can judge how far to trust a result.

The automated suite

Thousands of automated tests run on every change. Unit tests check each piece of code on its own: an option is parsed, a page range is read, a JPEG comes out at the size asked. End-to-end tests then open the built site in a real browser, drop a real file on each tool and inspect the result, in three browser engines: the ones behind Chrome and Edge, Firefox, and Safari.

A fourth run uses a phone-sized viewport with touch events, so the layout and the file picker are checked the way a phone sees them. The tests run against the same static files that are deployed, not a development build.

Real documents for the PDF tools

PDF is where tools fail quietly: a page that looks right but lost a font, a form that stopped being fillable. The PDF tools run against a corpus of real-world documents from many producers, plus files built to be awkward: broken fonts, nested layers, scans. Open, save and edit are compared with the original, pixel by pixel, outside the edited area.

The PDF editor goes further, with a benchmark protocol written and hashed before the run: ten scripted operations, targets set in advance, independent validators on every saved file, and results published whether a target was met or missed. It measures the editor against the original file only.

Performance budgets

A page that loads slowly on a cheap phone is a tool nobody uses. Lighthouse runs on representative pages with budgets for the amount of script, the total weight, the time to the largest paint and the layout shift; a page that exceeds its budget fails the check like a broken test. The engines themselves, which can be large, are loaded only when a tool needs them.

These budgets protect the promise on the home page: the tool is in front of you before you finish reading, on a slow connection, with no waiting screen.

What is not tested yet, and how to tell us

Honest gaps: the real scanned PDFs in the corpus are few and the OCR benchmark uses synthetic scans; speed on phones is checked by smoke tests, not measured; certificate signatures have a small test set; and no automated test knows what your particular file looks like. If a tool gives a wrong result, tell us on the Request a tool page or in the feedback box under the tool, with the browser and what you expected. File names and contents are never sent with it; describe them in words.