How to compress a JPG or PNG to 200 KB without losing readability
Reduce image file size in a sensible order: pick a format, keep required dimensions, adjust quality, and verify the actual byte count.
The form says "max 200 KB" and the photo on your desktop is 3.2 MB. You have tried dragging the quality slider around, and the number jumped from 3.2 MB to 480 KB to 90 KB with nothing useful in between. That jump is not a bug in your software. File size and image quality are linked by a curve, not a dial, and the fastest way through is to change things in the right order.
First, check what "200 KB" means
Bytes, KiB and rounded labels
AttachReady's 200 KB preset means 200,000 bytes. Some software displays KiB instead, where 200 KiB is 204,800 bytes, and many file managers round the number they show you. A file your computer labels "200 KB" can be 204,000 bytes and still fail a portal's hard limit.
So compare raw byte counts, not the rounded label. If you cannot tell which unit the receiving site uses, aim for 190,000 bytes or so and stop worrying about it.
Pick a format the destination accepts
What each format is good at
Format decides what the encoder is allowed to throw away. JPEG is happy to discard fine detail; PNG refuses to.
| Format | Good for | Weak at | Watch out for |
|---|---|---|---|
| JPEG | Photos, scans, anything continuous-tone | Sharp text, flat colour blocks | No transparency; every save recompresses |
| PNG | Screenshots, logos, signatures, transparency | Photos | A photographic PNG can be 5–10× the JPEG |
| WebP | Both, roughly 25–35% smaller than JPEG at similar quality | Very old upload forms | Some portals still reject the extension |
| AVIF | Smallest files at high quality | Encoding speed, older readers | Support varies widely by browser and portal |
The rule that overrides the table: if the portal only accepts JPEG, send JPEG. A 40 KB WebP that the upload field refuses is worse than a 180 KB JPEG that goes through.
When the format itself is the blocker
If your source is a HEIC photo from a phone or a PNG screenshot, convert first, then compress. Changing the file extension in Finder or Explorer does not convert anything — the bytes stay in the original format and the portal will detect that. Use image conversion when the format itself is the blocker.
Why shrinking pixels does not shrink bytes proportionally
The 8 × 8 block explanation
A 4000 × 3000 photo reduced to 1200 × 900 keeps its aspect ratio and uses 9% of the original pixels. It is tempting to expect a 91% smaller file. That is not what happens, and the reason is worth knowing because it tells you where the real savings live.
JPEG does not store pixels one by one. It splits the image into 8 × 8 blocks, applies a discrete cosine transform to each block, and then quantises the resulting coefficients — dividing them by values from a quality table and rounding. Most of the visual information in a natural photo sits in the low-frequency coefficients (overall brightness and colour gradients), and those survive quantisation well. What gets thrown away first is high-frequency detail: noise, fabric texture, individual hairs, the crisp edge of a signature.
Two consequences follow:
- Quality and bytes are not linearly related. Going from quality 95 to 85 might halve the file with almost nothing visible. Going from 60 to 50 can look noticeably worse while saving very little, because by then most of the easy data is already gone.
- Detail costs bytes, not pixels. A 1200 × 900 photo of a brick wall is much larger than a 1200 × 900 photo of an empty sky at the same quality setting, because the wall has high-frequency content in nearly every block.
Chroma subsampling and coloured stamps
There is a second mechanism: chroma subsampling. Human vision resolves brightness far better than colour, so JPEG normally stores colour at half resolution (4:2:0) and keeps full-resolution brightness. That is why aggressive compression smears red text or coloured stamps before it blurs black text — and why a document with coloured seals and signatures is harder to compress than one that is black on white.
Converting a transparent PNG to JPEG
Check the fill colour and the edges
JPEG has no alpha channel. Convert a transparent PNG and every transparent pixel must be filled with a colour — usually white, sometimes black, depending on the tool. Get the fill wrong and a cut-out signature on a dark logo becomes an invisible blob or gains a grey halo.
Check the result at 200% or more: the outline of the signature or cut-out, the anti-aliased fringe around it, and any thin strokes. A common failure is a scan where the "white" background is actually light grey; flattening it to pure white makes the cut-out edge look jagged, while leaving it grey makes the file larger. In that case keep PNG and compress harder instead, or crop tighter to remove the empty area.
A repeatable five-step workflow
- Read the rules and keep the original. Note the accepted formats, the byte limit, and any pixel requirement. Work on a copy so you can always start over from the source.
- Open the image compressor, add the file, and pick an output format the portal accepts.
- Set the target to 200,000 bytes — or whatever the real number is. Turn on strict mode if the limit is mandatory and a rejection would cost you the submission.
- Inspect the output at readable size. Zoom into fine print, faces, stamps and high-contrast edges. Check the reported byte count against the limit.
- If it will not fit, reduce dimensions rather than quality — and only when the rules allow smaller pixels. Then run it again from the original, not from the already-compressed output.
That last point matters. Recompressing an already-compressed JPEG throws away more data on top of the loss you already accepted, and the artefacts compound. Always restart from the original file.
When to stop compressing and re-scan instead
Fixes that work better than more compression
Some inputs will not reach a small target while staying readable. Very noisy scans, handwriting in a light pencil, a stamp photographed under mixed lighting, or a portal that also demands a minimum pixel count — those constraints fight each other, and no setting resolves them.
When you hit that wall, these work better than more compression:
- Re-scan or re-photograph with even lighting and no shadow across the page.
- Scan in grayscale if the submission does not require colour. It removes the chroma channel entirely, which is often where much of the data goes.
- Crop out irrelevant margins and desk background, if the rules permit it.
- Ask the receiving organisation whether another upload route exists.
The honest limit: a fixed byte target cannot guarantee lossless output. At 200,000 bytes something has to be discarded, and if the source is detailed enough, that something will be visible. Strict mode does not mark a non-conforming output as a success — if it fails, that failure is the answer, and the fix is upstream at the scanner.
Removing metadata helps privacy but is not a reliable way to shrink a photo to 200 KB. Changing only the DPI tag does not change the pixel count at all. Read pixels versus DPI before adjusting either, and check formats and limits if a file keeps getting rejected for reasons the size check does not explain.
AttachReady runs browser-local image compression and separate server-side tools. Read the notice on the control you use — the privacy guide describes what stays on your device and what does not.