Compress an Image to an Exact File Size
Type the number the upload form demands and the page searches for the quality that lands there.
Every attempt is encoded in this tab — no upload, no file capReduce image size in KB — 20, 50, 100, 200 KB or any target you set
or drag & drop them here, or paste one from your clipboard (Ctrl+V). Drop as many as you like — no file cap, no size cap, no queue.
JPG · PNG · WebP · GIF · AVIF
In target mode the engine binary-searches for the best quality that still fits the size you asked for: up to 9 re-encodes per file, and it tells you how many it took. It never hands back something over the target without saying so.
PNGs are not compressed here. A browser canvas can only ever write 8-bit RGBA PNG, so re-encoding one returns the same bytes it was given. A PNG therefore comes out as WebP, which has real compression — and the actual byte counts are still compared, because that trade is image-dependent: on a noisy image the WebP can come out larger.
Results
Choose your images and every file shows up here with its original size, its new size, the real change, the quality used and how many encode passes it cost.
Before and after
The comparison lands here: original on the left, result on the right, and you drag the line to judge for yourself whether the quality is acceptable.
How it works
Everything runs in your browser: images are never uploaded, there is no account, no queue and no daily limit. Re-encoding also drops the original EXIF metadata, GPS location included — if stripping that without re-compressing the photo is what you actually want, use the EXIF viewer and remover.
About this target-size image compressor
Type the number the upload form gave you — 50 KB, 100 KB, 1 MB, or anything else — drop in your images, and the page re-encodes each one over and over, narrowing in on the quality setting that lands closest to your figure without going over it. Every file gets its own row: the size it started at, the size it actually reached, the quality it settled on and how many encode passes that cost. A file that already fits is handed back untouched instead of being re-compressed for nothing, and a before-and-after slider lets you drag across the two versions and judge the result yourself. Output is JPEG or WebP, batches have no cap, and you can take the files one at a time or all at once as a ZIP.
That is a different instrument from the one the well-known compressors hand you. TinyPNG runs an automatic pass; Squoosh, iLoveIMG and Compressor.io give you a quality slider. All good tools; none takes a number. But you rarely arrive here wanting “quality 0.6” — you arrive because a job portal, a visa application or a mail server said the file has to be under a specific size, and the honest interface for that is a field you type the size into. Other target-size compressors do exist, mostly on small tool sites and on img2go, which does the work on its server.
There are no limits here, and that is architecture rather than generosity. iLoveIMG caps a free compression task at 30 files and 200 MB; TinyPNG’s free tier takes 20 images at a time at 5 MB each; CloudConvert gives free accounts 10 conversions a day. Those numbers exist because every file costs the vendor CPU time and bandwidth. Nothing here reaches a server, so there is no meter to run: no daily allowance, no task counter, no per-file ceiling, no account, no watermark and no email address.
Now the phrase everybody searches for, answered rather than repeated: this does not compress “without losing quality”. Squeezing a 4 MB photograph into 50 KB is lossy by definition, and this is the one page where you can verify that in ten seconds. What a lossy encoder discards is the fine detail your eye weights least — sharp variation over a few pixels, plus some colour precision — which a photograph hides beautifully and a screenshot full of text does not. The distinction worth keeping is between no loss and no visible loss: a generous target usually buys the second one, a brutal target will not, and the page tells you the number it actually reached instead of quietly missing.
One thing this deliberately does not do is compress PNG. A browser canvas always writes 8-bit RGBA PNG and cannot build a palette, so it cannot quantise colours — the one operation that meaningfully shrinks a PNG. Measured here, a PNG round-tripped through a canvas came back at exactly the 58,020 bytes it went in at. So a PNG is flagged and offered WebP instead, which genuinely can be smaller — though not always: on random noise that same file came out larger as lossless WebP, 58,192 bytes. You get the real counts either way. One side effect worth a line: re-encoding drops EXIF, so the copy you download carries no GPS tag — if that was the goal, the EXIF tool does it without touching a pixel.
What compression actually throws away, and what survives it
Lossy compression is not “making the file smaller”. It is deciding what information to destroy. A JPEG encoder converts the picture into brightness and colour channels, cuts it into 8×8 blocks, runs a discrete cosine transform over each block and then divides the resulting coefficients by a quantisation table — that division, and the rounding that follows it, is where the information actually disappears. Turning quality down scales that table up so more coefficients round away to zero. Most of what goes is high-frequency detail: sharp variation across a few pixels. Both JPEG and lossy WebP also throw away colour resolution before any of that: lossy WebP always stores the colour channels at half width and half height, and JPEG encoders normally do the same except at the very top of their quality range, because human vision resolves brightness far better than it resolves colour.
Which is why what you are compressing matters more than what you set the dial to. The same target that is invisible on a holiday photo is brutal on a screenshot, and no amount of tuning changes that — the encoder is throwing away exactly the kind of detail a screenshot is made of.
| What you are compressing | How it behaves | What to do |
|---|---|---|
| A camera photograph | The best case. Foliage, skin, fabric and sensor noise are precisely the high-frequency detail the encoder discards, and your eye has no reference for what was supposed to be there. Large savings arrive long before anything looks wrong. | JPEG or lossy WebP, and you can be fairly greedy with the target. |
| A screenshot containing text | The worst case. Text is hard black-on-white edges — the highest-frequency content there is — and you know exactly what a letter is meant to look like, so the ringing and blur around it are obvious immediately. | Keep it as PNG, or use lossless WebP. A hard KB target on a screenshot will look bad well before it looks small. |
| A logo or flat-colour illustration | Few colours, hard edges, large flat areas. Lossy compression invents noise in the flat areas and haloes along the edges, and the file was not large to begin with. | PNG or SVG. If it truly must shrink, lossless WebP — Google measures that at roughly 26% below the equivalent PNG. |
| A smooth gradient | Deceptive. It compresses to very few bytes and still bands visibly, because the eye is unusually good at spotting a stepped ramp in a sky or a background. | Check the result at full size rather than trusting the byte count. |
| Anything with transparency | JPEG has no alpha channel at all, so a transparent background becomes a solid colour — usually white, and usually a surprise. WebP carries alpha in both of its modes. | Use WebP whenever the file must be both small and transparent. |
| A master you will edit again later | Every re-encode compounds the previous one. Generation loss is cumulative and irreversible; there is no way back to the original detail. | Compress a copy for the upload and keep the original untouched. |
Between the two formats this page can write, the short version is that WebP is usually the better encoder and JPEG is the safer file. Google’s own figures put lossy WebP 25–34% below a comparable JPEG at equivalent quality on the SSIM index, and WebP additionally supports transparency, which JPEG cannot. But a government upload form that says “JPG only” means it, and a decade-old desktop program may still refuse a .webp outright. Choose WebP when you control what opens the file, and JPEG when you do not.
And treat the quality number itself with suspicion, because it is not a unit. “Quality 80” is not defined anywhere in the JPEG standard; it is a convention inherited from the reference implementation, where it scales a quantisation table. WebP’s quality parameter drives a completely different encoder. So a JPEG at 80 and a WebP at 80 are not comparable, two different JPEG encoders at 80 need not produce the same file, and MDN describes the browser’s own quality argument merely as a number between 0 and 1 for formats that use lossy compression, defaulting to 0.92 when you say nothing. That is the strongest practical argument for typing a size rather than a quality: the size is a real, comparable, verifiable unit, and the quality number is a dial on somebody else’s machine.
Why a file-size target needs a search, and when the number is impossible
There is no equation that turns a quality setting into a file size, because the size depends on the picture. Two 12-megapixel photos at identical settings can differ by a factor of five — a foggy landscape compresses down to almost nothing, a forest full of leaves does not. So the only way to land on 100 KB is to encode, measure, adjust and encode again. That is what happens here: the page brackets the quality range, bisects it, re-encodes on each step until it converges on the largest file that still fits under your number, and then reports the quality it stopped at. A dozen encodes of a large photograph is real work, which is exactly why the incumbents sell you a slider instead — on a server every iteration is CPU somebody is paying for. In your own browser the loop costs nothing, and that is the whole architectural argument for this page existing.
The second thing worth understanding is that a target can simply be out of reach, and when it is, the cause is almost never quality. It is pixel count. The useful way to think about it is bits per pixel: take the target size in bits and divide by the number of pixels in the image.
| Image | Pixels | At a 100 KB target | Verdict |
|---|---|---|---|
| 4000 × 3000 phone photo | 12,000,000 | about 0.07 bits per pixel | Not achievable at any acceptable quality — roughly a tenth of what aggressive web compression uses. |
| 2000 × 1500 | 3,000,000 | about 0.27 bits per pixel | Aggressive but usable on the web. Fine detail will smear. |
| 1200 × 900 | 1,080,000 | about 0.76 bits per pixel | Comfortable for a photograph. |
| 1000 × 750 | 750,000 | about 1.09 bits per pixel | Good quality. Most photos look untouched here. |
| 600 × 400 thumbnail | 240,000 | about 3.4 bits per pixel | The target is not the constraint at all — you reach 100 KB with quality to spare. |
Those are rules of thumb rather than a specification: a photograph tends to look clean somewhere around 1 bit per pixel and starts visibly falling apart well below 0.3, and line art behaves differently again. What the table really says is that the fastest route to a small target is to send fewer pixels. If a form demands 50 KB, a 4000-pixel-wide original is the problem and the encoder is not — which is why this page reports “the closest was 112 KB at quality 0.41” instead of quietly handing you a file that misses the limit.
- Read the limit properly. “Under 100 KB” and “maximum 100 KB” are the same instruction, but “between 50 KB and 100 KB” is a band — and some portals reject a file for being too small just as readily as for being too large.
- Resize before you compress if the image is far larger than it will ever be displayed. A photo attached to a form is going to be looked at in a box a few hundred pixels wide, not at 12 megapixels.
- Compress a copy, never your only original. Every pass is irreversible and they stack on top of each other.
- Match the format to what the receiving system accepts. If the form says JPG, a WebP is rejected at the door no matter how good it looks or how small it is.
- Judge the result at 100%, not in a thumbnail. Compression artefacts hide at small sizes and appear the moment somebody zooms in.
- Check the size you actually got, not the one you asked for. If the page reports 112 KB against a 100 KB limit, the upload still fails — and it is better to learn that here than at the form.
FAQ
Can I compress an image without losing quality?
Not to a small target, and it is worth being precise about why. JPEG and lossy WebP work by discarding information permanently, so any real reduction is a real loss — what changes is whether you can see it. Going from a 4 MB photo to 1 MB is usually invisible on a photograph; going to 50 KB is not, especially on text, logos and flat colour. True lossless compression exists, but it saves far less: lossless WebP is around 26% below the equivalent PNG by Google’s own measurement, which will not get a phone photo under 100 KB. The practical middle ground is to set the most generous target the form allows, keep the pixel dimensions modest, and judge the result at full size rather than at thumbnail size.
Why can’t I compress a PNG here?
Because a browser cannot do it honestly. The only thing that meaningfully shrinks a PNG is quantising the image down to a colour palette, and a canvas always emits 8-bit RGBA PNG with no palette at all. Measured on this site, a PNG re-encoded through a canvas came back at exactly the same 58,020 bytes it went in at — a tool that returns your file unchanged and calls it compressed is worse than no tool. So PNG input is detected and offered two real routes instead: convert to WebP, which can be substantially smaller but is image-dependent, or convert to JPEG if you accept losing transparency. Either way the page shows the actual before and after bytes rather than a promised percentage.
What happens if it can’t reach the size I asked for?
It tells you. The page reports the closest it got and the quality it stopped at — “112 KB at quality 0.41” — rather than handing back a file that silently misses your limit, which is the failure mode that gets an upload rejected. When a target is unreachable, the cause is almost always pixel count rather than quality: a 4000 × 3000 photograph squeezed into 100 KB has about 0.07 bits per pixel to work with, roughly a tenth of what aggressive web compression uses. The fix is fewer pixels, and the page does not leave you to work that out: when quality alone cannot get there, it proposes a specific cap for the longest side and re-runs the search at that size if you accept. Scale an image down to something close to how it will actually be viewed and the same target becomes comfortable — the table further down this page shows where the line falls.