Target Size
Compress an image to 200KB without guessing the quality
Set 200 KB as a ceiling and OptiSqueeze searches for the highest quality that still fits under it — no trial-and-error with a slider, no re-encoding five times. It runs the whole search on your own device, so the seven test encodes never leave it.
Tap to choose your photosDrop an image anywhere, or browse files
Supports WebP, JPEG, PNG, and AVIF up to 50MB. Processed offline.
Target size is already set to 200 KB — adjust it after you drop a file.
Why 200 KB is the size people ask for
A 200 KB limit is almost never arbitrary. It is what a form will accept: job applications and recruitment portals, university and admission submissions, tax and government filings, exam photo uploads, and email clients with attachment ceilings. The requirement is exact, and it is usually enforced by a rejection message after you have already spent time preparing the file.
That changes what “good compression” means. On a website you are optimising a budget you set yourself, so you can trade quality against size freely. Here you have a hard ceiling and want the best image that fits — which is the opposite problem, and the one a target-size search solves.
How the compressor hits a target size
Rather than asking you to pick a quality number, it runs a bounded binary search: encode at a middle quality, look at the resulting size, then move up or down and try again. Each pass roughly halves the range still in play, so a handful of encodes converge on the highest quality under your limit. The bounds depend on the codec — JPEG and WebP get seven passes between quality 5 and 95, while AVIF and PNG get five passes over a slightly narrower range, because those encodes cost much more time per attempt.
If no quality level inside those bounds fits, the compressor has one lever left: pixels. When “preserve dimensions” is off, it scales the image to 75% and repeats the search, up to three times. That is deliberate — reducing dimensions usually preserves far more perceived quality at a given byte budget than driving the quality value down, because a file’s cost is dominated by how much detail it has to describe.
When even that fails, the tool returns the smallest file it could make and displays its actual size. It will not quietly hand you something over the limit and let you assume it fits.
Getting an image under 100KB, 50KB or 20KB
The same mechanism covers any ceiling — tap a preset or type your own. What changes is how much you have to give up, and roughly where the wall is:
- 200 KB — a typical 2–4 MB photo from a phone or camera usually fits with quality to spare, often without any downscaling. This is the comfortable case.
- 100 KB — still very achievable for a document scan, a screenshot or a headshot. A large landscape photo may need its dimensions reduced.
- 50 KB — expect visible softening on detailed photos. Fine for a small portrait or an image that will be displayed narrow.
- 20 KB — a genuinely tight budget. Plan on resizing; at typical photo dimensions the encoder cannot describe enough detail to fit otherwise. This is where signature scans and passport-style crops work well and full scenes do not.
- 1 MB or more — the ceiling forms ask for high-resolution documents, where the goal is usually just “smaller than it is now”.
If you are aiming at a portal’s limit, always check the final number against it before uploading. “About 200 KB” and “under 200 KB” are not the same answer to a validation script.
The format you choose changes how easy the target is
If the destination accepts it, compressing to WebP usually reaches a byte target at a visibly better quality than JPEG, and AVIF typically goes further again — at the cost of slower encoding and patchier support. Use JPEG when a portal is fussy about file types (several will reject anything it does not recognise as a photograph), and PNG only when you need exact pixels or transparency, since it has no lossy lever to pull. WebP vs AVIF vs JPEG covers the trade-offs.
Sizing a passport or visa photo is the one target-size job with a second hard constraint — exact pixel dimensions as well as a byte ceiling. The passport photo tool renders the official sizes (35 × 45 mm, US 2 × 2 in) to spec and checks both numbers for you.
Privacy, and why it matters more for size targets
Reaching a file size is iterative: the image is encoded up to seven times before the search settles. On an upload-based service, every one of those passes is a copy of your photo leaving your device. Here the search runs locally in WebAssembly and only the final file is ever saved.
This is also the part of “it runs in your browser” that you can check rather than take on faith — this guide walks through verifying it in DevTools in about a minute. If a document is sensitive enough that uploading it would be a problem — an ID, a medical image, a signed form, a client’s artwork — that verifiability is the whole reason the page exists. See also stripping EXIF metadata, which removes the GPS coordinates a camera leaves behind.
Limits, honestly
Input files go up to 50 MB, and the browser has to hold the decoded image in memory, so very large photos on a low-RAM device can fail where a desktop service would not. AVIF encoding is the slowest option. Target-size search is bounded: an image whose content is genuinely too complex for the budget comes back as the best effort, not a guarantee.
Target size questions
Drop the image in, set the target size to 200 KB, and leave the quality slider alone. The compressor encodes the image repeatedly at different quality levels and keeps the highest one that still lands under 200 KB — so you get the best possible picture inside the limit rather than a guess at a quality number.
It will not always reach the target. If a photo cannot be fitted to 200 KB at a usable quality, the tool returns its closest attempt and shows you the real size, so you always know whether you are under the limit.
Yes — the target size is a free number, and 20, 50, 100, 200, 500 KB and 1 MB are one tap away under the Target Size field. Everything on this page applies to any of those ceilings.
The lower you go, the more the encoder has to trade. A 20 KB budget is usually only reachable by shrinking the pixel dimensions too, which is why a small target and “preserve dimensions” are often mutually exclusive.
Usually it helps far more than pushing quality down. File size scales roughly with the number of pixels: halving each side removes about three quarters of them. Turning “preserve dimensions” off lets the compressor downscale in steps when quality alone cannot reach your target, which typically looks much better than the same image at an aggressive quality value.
This one. The size search happens on your device: every test encode is produced locally by WebAssembly, so no intermediate version is ever transmitted. Open DevTools, watch the Network tab, and run a compression — you will not see a request carrying your image.
That matters more here than in a normal compressor, because hitting a target size means the tool encodes the same photo up to seven times. Upload-based services send all of those attempts to a server.
Three common reasons. A very large photo has too many pixels for the encoder to discard enough detail. A PNG with flat colours and text can be re-encoded losslessly but has no lossy lever to pull, so switching to WebP usually beats shrinking it. And an image with a lot of fine noise or grain costs disproportionately many bytes at any quality.
If the target genuinely cannot be met, the honest options are a larger allowance, smaller dimensions, or a different format.
Not sure which format to aim for? Start from the full compressor or read the guides.