How these tools are tested
Anyone can claim an image tool hits an exact file size. This page says how that claim is checked, so you can judge it rather than take it on trust.
An automated test suite runs before every release
The sizing engine has 87 automated tests that must pass before the site is published. They are not tests of the interface; they test the arithmetic and the file format handling that decide whether your upload is accepted. In outline they cover:
| Area | What is checked |
|---|---|
| Reading your target | That "20", "20kb", "20 KB", "1.5 mb" and "500b" mean what you expect, and that nonsense, zero and negative values are refused rather than guessed at |
| Dimensions | Exact boxes such as 140 × 60, width-only and height-only with the aspect ratio preserved, fitting inside a box, never enlarging past the original, and never producing a zero-pixel image |
| Hitting the size target | That the search finds the highest quality that still fits, respects the cap, stays close to it, and is bounded to at most 16 attempts — including against a deliberately erratic encoder |
| Impossible targets | That a target which cannot be met reports failure honestly instead of returning an oversized file |
| Minimum sizes | That padding reaches the exact byte count, keeps the file a valid JPEG, preserves every original byte, and is skipped when the file is already large enough |
| Camera rotation | That the EXIF orientation flag is read correctly in both byte orders and all eight values, that a portrait photo shot in landscape comes out upright, and that a damaged or absent tag falls back safely instead of failing |
| Real scenarios | That a 10–20 KB exam window, a 20–50 KB photo window, a 10 KB maximum and a 1 MB cap on a five-megabyte phone photo are all reachable |
How a size target is actually reached
JPEG quality is not a percentage of file size — the relationship between the two differs for every image. The engine therefore encodes the image repeatedly at different quality settings and narrows in on the largest file that still fits your limit, which is why the result sits close under the cap rather than far below it.
When a file falls below a required minimum, nothing is stretched or blurred to make it bigger. Padding is placed in a JPEG comment segment, a part of the format every decoder skips. The byte count rises to meet the rule and the pixels are bit-for-bit identical. The tests confirm both halves of that: the exact byte count, and that the original bytes are untouched.
What these tools cannot do
Stated plainly, because a tool that hides its limits wastes your time:
- HEIC photos from iPhones cannot be opened by most desktop browsers. Set the camera to "Most Compatible", or share the photo to yourself, which converts it to JPG.
- PNG cannot be tuned to a byte target. It is lossless, so its size is decided by the image's content. To hit a KB limit, choose JPG.
- Results vary slightly between browsers. The encoder belongs to your browser, not to this site, so the same image at the same setting can differ by a few hundred bytes between Chrome, Safari and Firefox. Every target is met with that variation allowed for.
- Very large images are limited by your device's memory, since the work happens on your device rather than on a server.
- No tool can guarantee acceptance. Portals enforce their own rules, and some check things no resizer can influence — a plain background, a recent photograph, a visible face.
Check the privacy claim yourself
The claim that images never leave your device is not something you have to believe. Load a tool page, disconnect from the internet, and process an image: it still works, because the processing is JavaScript running on your machine. A tool that uploaded your file could not do that.
Corrections
If a tool produces a file that a form rejects, that is worth knowing about — the details on the contact page are what make a report actionable.