Input reference
Use screenshots the browser can decode consistently.
A filename extension is not proof of an image’s contents. The browser must successfully decode each file before the workbench can compare it.
Current image inputs
| Format | Status | Review notes |
|---|---|---|
| PNG | Preferred | Lossless and well suited to UI screenshots, crisp text, and repeatable pixel comparison. |
| JPEG / JPG | Accepted when the browser decodes it | Compression artefacts can create noisy differences around text and edges. |
| WebP | Accepted when the browser decodes it | Lossless WebP can work well; lossy WebP introduces the same interpretation risk as JPEG. |
| GIF, SVG, HEIC/HEIF, AVIF, TIFF, PDF | Not part of the documented input contract | Convert a still screenshot to PNG before review. Do not rename an extension. |
Exact size and project limits
Each image must be non-empty, no larger than 25 MiB, no more than 12,000 pixels on either axis, and no more than 16,777,216 decoded pixels. A file selected for restore must be no larger than 96 MiB, while the validated model also enforces an estimated 90 MiB portable-backup budget. The project model accepts at most 128 effective target locales, 2,000 screenshot records per side, 10,000 coverage-matrix cells, 50 additional issues per review, 10,000 additional issues overall, and 536,870,912 aggregate screenshot pixels. Intake is rejected before image bytes are stored when the resulting project would cross these limits.
Automatic pixel diff is capped at 8,388,608 output pixels on ordinary desktop layouts and 4,194,304 on constrained or compact layouts. Larger accepted captures remain reviewable in side-by-side, swipe, overlay, blink, region, and pixel-loupe modes; Run once offers an explicitly warned attempt. These are application safety ceilings, not a promise that every device can process a project at the ceiling. Browser canvas and memory limits vary. Split a large review by product area, platform, release, or locale group before it approaches a limit, then keep each exported project in approved storage.
- Capture only the relevant viewport when possible.
- Split very tall pages into stable, labelled segments.
- Keep baseline and localized images at identical pixel dimensions for direct overlay and difference review.
- If the browser reports a decode or memory error, resize outside the workbench with a trusted local tool and document the conversion.
Colour and transparency
Browsers may convert embedded colour profiles while decoding. Screenshots produced on different operating systems or display pipelines can therefore differ even when the interface values match. Transparent pixels are composited by the comparison canvas; use the same capture background for both files.
Do not interpret a colour difference as a localization issue until capture host, profile, theme, and rendering engine are controlled.
File safety
An image can contain sensitive information and metadata. The workbench does not need EXIF location or camera data, but source files may still contain it. Sanitize outside the app when policy requires it. Avoid files from untrusted sources, keep the browser updated, and do not attempt to compare executable or document formats disguised as images.
Questions about imports
Why does the same screenshot look different after JPEG conversion?
JPEG approximates pixel values. Small ringing and block artefacts are particularly visible around high-contrast UI text and can dominate a difference view.
Can different-sized images still be reviewed?
They can be observed side by side, but direct pixel alignment is not equivalent evidence. Re-capture matching viewports whenever possible.
Does acceptance mean every browser supports the file equally?
No. Decoding support, memory ceilings, and colour handling vary by browser version and device. PNG is the most predictable documented choice for this workflow.