Compress Image to KB — Pick Any Exact Target

Take the seller who lists on Amazon. The photo studio delivers hero shots at 3000 pixels wide because that is what the camera shoots, and each one weighs 6 to 10 MB as an exported JPG. Amazon wants a clean white-background main image, and while the platform accepts files up to 10 MB, a catalog of 200 SKUs at 8 MB apiece means a 1.6 GB upload that takes forever and makes every later edit slow. Pushing each master shot down to around 1200 pixels and re-encoding to a few hundred KB keeps the listing sharp on every device, passes the white-background check with no visible banding around the product edges, and shrinks the whole batch to a fraction of the original weight. The trick is doing it per image with a fixed byte target instead of one global quality setting — a white t-shirt on white and a black camera bag need very different quality levels to land at the same file size, and a fixed KB target handles both automatically.

Wedding photographers live inside the same math at a harsher scale. A typical delivery is 200 or more edited frames exported as JPGs at roughly 8 MB each — call it 1.6 GB of pixels. Most client cloud drives start at 2 GB free, so one wedding eats the whole quota, and the gallery link chokes on hotel wifi when the couple tries to show their parents. Re-encoding each frame to about 1 MB cuts the delivery to roughly 200 MB: the link loads in seconds on a phone, the drive stays under its free ceiling, and at screen-viewing sizes nobody can spot the difference. A 1 MB JPG at 2500 pixels holds up fine on a 27-inch monitor; what it will not survive is a 20x30-inch print, so photographers keep the full-resolution masters on their own drives and compress only the gallery copy — which is exactly what the bride and groom actually look at.

Visa and immigration photos are the most punishing case because the limits are tiny and the stakes are high. Australia's online visa forms reject photos over roughly 500 KB, and a straight-out-of-camera JPG sits at 5 to 8 MB. UK passport-style digital uploads behave the same way. So a traveler snaps the required photo against a plain background, opens it here, sets the target under the posted limit — 240 KB is a comfortable margin under a 500 KB cap — and gets a file that sails through. The photo needs to keep its dimensions close to the required 600x600 or 45mm-equivalent crop, so the smart order of operations is: crop to spec first, then compress with resizing disabled so the geometry never shifts. A rejected upload costs a re-shoot or a delayed application; a file that is 238 KB with the same face, background, and dimensions costs nothing.

A kilobyte is 1,000 bytes. A kibibyte is 1,024 bytes. Both get written as KB in everyday use, and the two produce different numbers for the same file. macOS reports sizes in decimal units, dividing by 1,000; a lot of Windows tooling and older software divides by 1,024 and still prints KB on the label. Neither one is lying — they are answering different questions.

The gap compounds as you climb the ladder. One step is 2.4 percent, and a megabyte is two steps, so the same bytes can read as 5.00 MB in one place and 4.77 MB in another. A form that says 2 MB might mean 2,000,000 bytes or 2,097,152, and nothing on the page will tell you which.

That is why this tool measures in raw bytes internally and why the size checker reports the exact byte count next to the kilobyte figure. Convert the form's limit to bytes yourself, compare the two, and the ambiguity evaporates. If you would rather not do arithmetic under deadline, leave a margin: a file at 90 KB passes a 100 KB cap under either convention, while one at 99.5 KB is a coin flip.

These are brackets, not universal rules, but the bracket you are in tells you what kind of fight you are facing. A 4 MB camera photo heading into a 2 MB government limit needs a 2x reduction, and quality alone handles that with room to spare. The same photo aimed at a 20 KB exam slot needs 200x, which no quality setting can deliver — the pixels have to come down, and the result lands around 400 pixels wide.

The third column is the one people skip. A cap on bytes and a minimum on pixels can be true at the same time — the DS-160 does exactly that — so shrinking dimensions to satisfy the size limit can push you under the pixel floor and fail the same upload for the opposite reason. Read both numbers before you pick a target.

The quality value is not a percentage of anything. It is an index into the JPEG quantisation tables — the divisors applied to an image's frequency coefficients after the picture is split into 8x8 blocks and transformed. Lower quality means larger divisors, more coefficients rounded down to zero, and fewer bits spent describing detail. Nothing is stored at 75 percent fidelity; the number only decides how aggressively detail is discarded.

The curve is steep at the top and flat at the bottom, and that shape is the most useful thing to know about it. Dropping from quality 90 to 75 commonly removes 40 to 50 percent of the bytes, and at screen sizes the difference is invisible, because the coefficients being thrown away describe exactly the detail the eye is worst at noticing. Going from 75 down to 60 saves another 20 to 30 percent, and that is where smooth gradients begin to band and small text goes soft. Below roughly 50, flat areas break into visible blocks.

An uneven curve is a bad thing to guess at, which is why this page shows you a byte target instead of a quality slider. Quality is the means; the requirement is bytes. The compressor binary-searches the quality range — encode at the midpoint, measure the real output, narrow the window — and finishes in about ten encodes per pass, under a second for a normal photo.

Both levers shrink the file, but they behave nothing alike. Halving each side of an image cuts the pixel count to a quarter, and for a photograph the bytes follow almost proportionally: a 4000x3000 shot at 12 megapixels reduced to 2000x1500 loses roughly 75 percent of its weight before quality is touched at all. Quality is the gentler lever and it is sublinear — every step down buys less than the one before, and it has a floor. Push a JPEG below about quality 30 and a photograph is unusable, so quality alone can typically buy somewhere between 8x and 20x and not much more.

That gives a decision rule. Under about 3x of reduction, leave the pixels alone and drop the quality — the image stays sharp, and any dimension requirement the form also imposes stays satisfied. Over about 10x, no quality setting will get you there; shrink the dimensions first and let quality trim the last stretch. In between, the content decides: a smooth portrait survives quality reduction far better than a textured product shot, because there is less high-frequency detail for the encoder to spend bits on.

When you use both, order matters. Resize first, then compress. Doing it the other way means encoding a full-size canvas at low quality and then discarding most of those pixels — you paid for detail you were about to throw away, and the interpolation runs over an image that already carries artifacts. The tool's own resizing follows that order: a full quality search runs at each size, and the dimensions only drop by 20 percent after that search has failed to reach the target. For the mirror-image problem — a file that is too small and needs to grow — see decrease image size in KB.

JPEG is lossy by design. It discards frequency detail the eye is least sensitive to, which is how it reaches roughly 10:1 over raw pixel data on a photograph. It is still the right choice for anything photographic, and it is the format this tool writes — which is why a transparent PNG comes out of it flattened onto white, since JPEG carries no alpha channel.

PNG is lossless: every pixel is stored exactly. For photographs that is a disaster, and a 12 megapixel photo saved as PNG weighs 8 to 15 MB. Where PNG wins is flat graphics. Screenshots, logos, charts, and interface captures with solid fills and crisp text compress to a fraction of their JPEG equivalent. PNG also has a second gear for that case: palette quantisation. Reducing an image to a 256-colour indexed palette can cut a screenshot by 60 to 80 percent with no visible change, because flat graphics rarely hold more than a few hundred distinct colours to begin with. pngquant and ImageMagick's -colors both do exactly this.

WebP is two formats sharing one container. Lossy WebP uses VP8 intra-frame coding and typically lands 25 to 35 percent under a comparable JPEG. Lossless WebP uses a different mode and usually beats PNG by around 25 percent. Browser support stopped being the problem years ago — Chrome, Firefox, Edge, and Safari from version 14 all read it — so it is the safest step down from JPEG whenever the receiving system accepts the extension.

AVIF is built on AV1 and is the smallest of the group, commonly around 50 percent under JPEG at matched visual quality, with the lead widening at very low bitrates where JPEG falls apart entirely. Two catches. Encoding is slow, several times slower than JPEG at the same settings. And support is newer: Safari only added AVIF in version 16.4, in 2023, and plenty of CMS upload filters still reject the extension outright. Check the destination before converting.

GIF caps at 256 colours per frame and compresses badly, so it only makes sense for animation. A six-second GIF at 900 pixels wide can easily reach 15 MB. The lever there is not quality at all — it is frame count, then frame size, then colour depth.

You do not have to pick a format before using the tool. Drop in whatever you have. Because the output is always JPEG, a photograph trapped inside a PNG stops being a PNG problem the moment it goes through, and that single conversion is often the largest win available anywhere on this page — a 6 MB PNG photograph becomes a 400 KB JPEG with no visible difference and no change in dimensions. If the reverse is what you need, reduce image size in KB covers the same ground from the size-first angle.

For one file, the tool above beats anything you can type. For a folder, the shell wins — with one catch. Most command-line flags set quality rather than size, so you are back to guessing and checking. A few tools break the pattern and take a byte budget directly.

# ImageMagick 7 — set quality yourself
magick input.jpg -resize 1600x1600\> -strip -quality 78 output.jpg

# ImageMagick 7 — hand it a budget and let it find the quality
magick input.jpg -strip -define jpeg:extent=100KB output.jpg

The geometry 1600x1600 with a trailing backslash-greater-than means shrink only if the image is larger than that box, and -strip removes EXIF along with the embedded thumbnail. The second form is the interesting one: jpeg:extent is a byte budget, and ImageMagick walks the quality down on its own until the output fits. On ImageMagick 6, replace magick with convert and keep every flag identical.

cwebp -q 75 -resize 1600 0 input.png -o output.webp
cwebp -size 102400 input.png -o output.webp
cwebp -lossless -z 9 input.png -o output.webp

cwebp's -size flag takes bytes, not kilobytes, so a 100 KB target is 102400. The -resize flag takes width and height, and passing 0 for height keeps the aspect ratio. The -z flag sets lossless effort from 0 to 9, where 9 is slowest and smallest.

ffmpeg -i input.jpg -q:v 5 output.jpg
jpegoptim --size=100k --strip-all *.jpg

ffmpeg's -q:v is a Qscale, not a quality percentage, and the scale runs backwards: 2 is near-lossless, 31 is the worst the encoder will produce, and 4 or 5 is the usual sweet spot for photographs. jpegoptim's --size flag is the closest command-line equivalent of what this page does — it re-encodes in place until the file fits the budget, and --strip-all drops EXIF and the embedded thumbnail in the same pass.

# Linux
for f in *.jpg; do printf '%8d  %s\n' "$(stat -c%s "$f")" "$f"; done

# macOS
for f in *.jpg; do printf '%8d  %s\n' "$(stat -f%z "$f")" "$f"; done

Run that before and after. stat returns raw bytes, which sidesteps the KB-versus-KiB question completely — compare the number against the form's limit converted to bytes and there is nothing left to interpret.

Two things go wrong on mobile, and both cost you quality before you have compressed anything. The first is HEIC. Since iOS 11, iPhones save photos in HEIC by default — an HEVC-based format producing files around half the size of an equivalent-quality JPEG. That is excellent right up until a form asks for a JPG. Exporting to JPEG re-encodes the same pixels into a less efficient format and the file commonly doubles: a 1.5 MB HEIC becomes a 3 MB JPG. Nothing about the picture changed, only the container.

The second is the export path. Mailing a photo from the iOS Photos app runs it through a size picker — Actual, Large, Medium, Small — and every option except Actual re-encodes it. AirDrop between two iPhones re-encodes when compatibility is involved. In the share sheet, Export Unmodified Original and plain Export hand you different files: one is the HEIC with EXIF intact, the other a JPEG with much of that rewritten. Stack any of those on top of your own compression and you are compressing an already-compressed file, which is the workflow that actually produces the mushy result people blame on the compressor.

The clean route from a phone is to move the original to whatever machine is doing the compressing — AirDrop as a file, iCloud, or a cable — then compress once from that original straight to the target. If everything has to happen on the phone, convert and compress in one step rather than converting, saving, and compressing the saved result.

Android has the same problem under a different name. Modern Android phones write HEIF or JPEG depending on the app, and some camera apps apply enough noise reduction and sharpening that the file is already lossy in a way no encoder can undo. If a photo looks soft before you compress it, no KB target will bring the detail back.

This tool decodes your file with the browser's own image decoder, draws it to a canvas, and re-encodes it there. The bytes never become a network request. There is no server holding a copy, no upload queue, and no retention policy to read, because there is nothing to retain. Close the tab and the image is gone from memory.

That matters more than it sounds for the files people actually compress. Passport photos, visa applications, ID scans, insurance paperwork, signed contracts — those are the documents that arrive with a KB cap attached, and they are precisely the files you do not want sitting in a stranger's storage bucket. A server-side compressor has to receive the bytes to do its work, and how long the copy lives afterward is a matter of its terms of service rather than your preference.

There are practical consequences beyond privacy. The tool keeps working offline once the page has loaded, so a weak signal in a government office basement is irrelevant. Latency is your own CPU instead of a round trip, which is why a 200-image batch runs at the speed of your machine rather than the speed of a shared queue. And nothing is metered or capped per day, because there is no bandwidth bill to ration.

Three checks take about ten seconds and catch nearly every rejection. First, the actual byte count — not the rounded KB figure in your file manager. Drop the output into the image size in KB checker and read the raw number, then compare it against the form's limit converted the same way. This is the check that catches a KB-versus-KiB mismatch before the form does.

Second, the pixel dimensions. If the form also specifies a size — 600x600 minimum, 1600 pixels on the long edge — confirm the compression did not touch it. With resizing switched off, dimensions are untouched by design. With it on, they drop in 20 percent steps, so a 4000-pixel photo can come out at 3200, 2560, 2048, 1638, or 1310 pixels, none of which is a number a form is likely to accept if it also checks geometry.

Third, what is inside the file. Re-encoding drops EXIF — GPS coordinates, timestamp, camera serial number — and bakes the orientation flag into the pixels, so a photo that used to display sideways in one app now displays the same way everywhere. Two side effects are worth knowing. An Adobe RGB or ProPhoto source gets converted to sRGB, which can shift saturated colours slightly, and a wide-gamut ICC profile does not survive the trip. For a form photo or a listing image neither matters. For a colour-critical handoff, keep the original.

The number a form states is rarely the number its validator enforces exactly. Between the KB-versus-KiB ambiguity, a server that rounds up, and an upload pipeline that re-encodes on arrival, landing at 99.4 KB against a 100 KB cap is a coin flip.

Leave five to ten percent. For a 100 KB limit, aim for 90. For 500 KB, aim for 450. For a 20 KB exam photo, aim for 18. The cost of the margin is a few percent of quality nobody can see; the cost of missing it is another upload attempt, and on an exam or visa portal that can mean another day.

The slider moves in 5 KB steps from 5 KB to 1000 KB, so margin targets are easy to set. When your number falls between two steps, round down — 45 KB rather than 50 KB against a 50 KB cap.