Image preparation method
How exact-KB image compression works
An image can be visually acceptable and still fail a strict upload because the destination checks final bytes, pixels, format, or transparency. Exact-KB preparation is a measured output problem, not a slider setting.
On this page
What an exact-KB target actually means
A file-size rule applies to the encoded result, not to the original camera file and not to a quality percentage shown in an editor. Two images with the same dimensions can produce very different byte sizes because photographic detail, transparency, colour variation, and format all affect compression.
Aftermath treats a maximum as a ceiling and reports bytes from the result it produced locally. A passing result is therefore useful evidence that the file is under the selected local limit, but it is not a claim that an external form will accept the image for every other reason.
| Question | Why it matters | What to review |
|---|---|---|
| What pixels are required? | A huge canvas can remain too heavy even at low quality. | Use destination dimensions before reducing quality. |
| Which format is allowed? | JPEG, PNG, and WebP compress different image types differently. | Preserve transparency only when the destination accepts it. |
| What is the final byte count? | A quality slider is not the final file size. | Inspect the measured output result. |
Try it with a safe sample
Meet a file-size limit
Try a textured sample with small text. The result below came from the image processor, then was reopened and measured.
- Download the sample and open the image compressor.
- Choose JPG and a 100 KB maximum. Leave width and height unset.
- Compare the downloaded copy with the original. Check the small text.
| Original | 1,837,142 B |
|---|---|
| Size ceiling | 102,400 B (100 × 1,024) |
| Measured output | 101,224 B |
| Output dimensions | 1600 × 1000 px |
This tool uses 1 KB = 1,024 bytes. Some upload forms use 1,000. Check the exact limit. A separate 600 × 600 PNG test with a 100-byte ceiling correctly failed.
How we checked this
Synthetic samples. No personal files. Results can vary with browser encoders.
Tested: · Chromium 149.0.7827.55
Download measurements and file hashes · Testing method
Sample files are free to reuse under CC0.
Use dimensions before aggressive quality loss
When a photograph is far above a byte limit, reducing its canvas often protects more useful detail than repeatedly reducing JPEG quality. The right order depends on the destination: first honour required pixels, then choose crop or fit, then choose format and quality.
A screenshot with small text is a useful counterexample. Shrinking it too far can make text unreadable even if it passes the byte limit. The result needs a human visual check as well as a byte check.
- Use crop only when losing edge content is acceptable.
- Use fit with padding when the complete source must remain visible.
- Treat a low-byte result with obvious artefacts as a warning, not success.
A first-party result receipt is more useful than a guess
The browser workflow re-encodes a separate output and measures that output. The useful record is the selected target, output dimensions, format, byte count, warnings, and the fact that the original was not overwritten.
If the target is impossible without unacceptable damage, the correct outcome is a visible failure or warning. It is better to change the destination requirement, source, canvas, or format intentionally than to pretend a damaged image is ready.
What this guide cannot decide
An image under a byte limit may still be rejected for content, identity, licensing, face/background rules, device authenticity, account eligibility, or a portal change. Those decisions remain with the destination.
The values in an external upload notice can change. Use the specific destination’s current documentation before relying on a preset or guide.
Desktop tools and commands
Use a local tool