How We Test & Verify
Quick answer
How we build and verify
- 1Local-first. Wherever possible, tools process your files in your browser — nothing is uploaded. The few tools that need a network service name it on their page and on the file privacy page.
- 2Tested. The shared image engine and content registry are covered by unit tests, and the image tools by end-to-end tests run against a production build in Chromium, Firefox and WebKit plus emulated Pixel 7 and iPhone 14 devices. Not every tool has an end-to-end test yet; we say which do below.
- 3Sourced. Reference facts cite primary/official sources and carry a visible “last verified” date.
- 4Honest. We label where each tool runs and never claim local processing for something that uploads.
What is actually under test
| Layer | What it checks | How it runs |
|---|---|---|
| Unit tests (Vitest) | Resize arithmetic, output-format choice, matte rules, filename sanitising, memory limits, the keep-original compressor rule, ZIP name de-duplication, GPS and DPI parsing, the content quality gate and site search | On every change, in Node |
| End-to-end (Playwright) | Image Studio, Image Compressor and Remove Image Metadata flows: upload, process, before/after stats, cancel, retry, ZIP download, keyboard names, mobile overflow | Against npm run build + start, in five browser projects |
| Privacy network audit | During a Studio run with JPG, PNG and WebP files: zero cross-origin requests, no large request bodies, no filename in any URL, no worker failures | Same Playwright suite |
| Platform checks | The reference page shows canonical, sources and a last-verified date; the format picker changes its recommendation; the checklist download is non-empty; retired URLs return 410 | Same Playwright suite |
| Security headers | Tests run under the real Content-Security-Policy-Report-Only headers; violations are inventoried and worker/script breakages fail the run | Same Playwright suite |
Format support is verified by hand, then gated in code
Every image format in the engine carries a support level — stable, experimental or planned — and the date it was last checked with a real canvas round-trip in current Chromium, Firefox and Safari (2026-06-19 at the time of writing). Only stable formats are offered: JPG, PNG and WebP for input and output. AVIF encoding is inconsistent across browsers, so it is marked experimental and hidden; HEIC decoding in the shared engine is marked planned and refused, while the separate HEIC to JPG tool uses a dedicated decoder library. A conversion is rated at the weaker of its two legs, so nothing is advertised that one browser cannot deliver.
How reference pages are sourced
A page may cite only entries in a central source registry. Each entry records the organisation, the URL, the date we accessed it, the date we last re-checked it and a reliability class (official platform documentation, primary technical documentation or a standards body). A unit test refuses to publish any reference page without a resolvable source, and any page without a tool, a verified source, a downloadable template or a concrete result. Where no official figure exists — most social media image sizes, for instance — the page says so in a warning rather than presenting community numbers as fact.
Dates are shown on the page itself, along with the change history, so you can judge freshness without trusting us. If you find a number that has drifted, the corrections page explains how to report it and how we handle the fix.
What has to be true before a tool is offered
Three checks gate every image operation. The format pair must be rated stable in the capability registry, or the option is simply absent from the menu. The processing strategy must be detected as in-browser before the green badge is rendered; a browser without canvas support sees a red notice and the run is refused rather than routed elsewhere. And the memory limits — 30 MB per file, 150 MB per batch, 100 files — must be encoded as warnings with unit tests, so the thresholds you see on the page and the thresholds the code applies cannot drift apart. The presets and recipes described on these pages are checked against the tool code by hand each time the page's verification date is updated, and the change history records when that happened.
What this does not guarantee
Browser encoders differ, so the file size a given quality setting produces varies between Chrome, Firefox and Safari, and between desktop and phone; our size examples are ranges, not promises. The memory limits shown in the image tools are advisory thresholds that trigger a warning, not hard caps, because browsers do not expose reliable free-memory figures. And a green test run shows the flows we scripted still work — it is not a claim that every tool has been exercised in every browser.
Last verified · reviewed occasionally.
Change history
- — Initial publication.