Reduce Image Size in KB

There is no single magic number. Every portal invents its own ceiling, and they rarely agree with each other. What follows is the honest map: the limits that actually show up on real forms in 2025, gathered from government portals, admissions systems, and professional platforms people use every day. Your specific form may differ — always check its help page — but if it asks for a photo or a scanned document, the odds are good it sits somewhere on this table.

Notice the pattern in the right-hand column: the smaller the ceiling, the more the pixel dimensions have to give way. At 240 KB a full-resolution phone photo fits without any resizing at all. At 100 KB you can usually keep the dimensions and lean on quality alone. At 20 KB you are trimming the photo to roughly 500 pixels on the long edge and hoping the portal's minimum-dimension check does not kick you back. That relationship — target size decides which lever moves first — is the single most useful thing to understand before you compress anything.

If you have ever opened an image editor and wondered why the quality slider seems to gravitate toward 75, that is not superstition. The number traces back to the reference implementations of the JPEG standard itself. libjpeg — the C library written by the Independent JPEG Group in 1991 that almost every piece of software still borrows from — ships with a default quality of 75, and Photoshop's classic 'Save for Web' presets and countless server-side processing pipelines inherited it directly. Three decades later, quality 75 remains the most-repeated encoding setting on the internet.

What the number actually controls is the quantization step. JPEG works in three stages: the image is cut into 8×8 pixel blocks, each block is converted into frequency coefficients by a discrete cosine transform, and then those coefficients are divided by a quantization table — the 'quality' setting scales how coarse that division is. At quality 75, the divisor throws away high-frequency detail the human eye registers poorly, which is why the file shrinks so dramatically while the picture still looks fine. Push quality to 95 and you keep almost everything, paying three to five times the bytes for detail most screens cannot show. Drop below 50 and the 8×8 block boundaries themselves start to show up as visible grid lines.

The third stage is where the real compression lives, and almost nobody talks about it: Huffman entropy coding. After quantization, the surviving numbers are encoded so that the most common values get the shortest binary representations — a scheme David Huffman worked out in 1952 as a term paper at MIT. Typical photographs have just the kind of skewed value distribution Huffman coding loves, and it squeezes the quantized data another 20 to 40 percent beyond what the quantization step alone achieved, with zero additional quality loss. It is completely lossless, which is the quiet miracle of the format: half of JPEG's magic costs nothing at all.

The practical takeaway for hitting a KB target: the slider setting matters less than landing the search correctly. A quality-78 encode of one photo can weigh more than a quality-72 encode of another, because content drives the entropy coder. That is why this tool binary-searches the quality until the byte count fits rather than guessing a fixed number — the same setting produces wildly different file sizes across different photos.

The most common mental math mistake in image compression goes like this: 'the photo is 4000 pixels wide and 2 MB, so if I make it 2000 pixels wide it should be about 1 MB.' It will not be. It will usually land somewhere between 500 KB and 700 KB — roughly a third to a half of the original, not a half.

Here is why. Halving both the width and the height cuts the pixel count to one quarter — 4000×3000 is 12 million pixels, 2000×1500 is 3 million. File size follows pixel count, not width. So the naive estimate is off by a factor of two right from the start, and then entropy coding bends it further: after resizing, the remaining pixels are averaged from their neighbors, which smooths local detail, which makes the quantized coefficients more predictable, which lets the Huffman stage squeeze even harder. The result is that the file shrinks disproportionately — area says 4×, the bytes usually say 3× to 4×, sometimes more on noisy photos where downsampling averages away sensor grain.

The same nonlinearity runs in reverse, and it is why quality and dimensions are different kinds of levers. Quality reduction is roughly proportional in its useful range — sliding from quality 90 to 75 often halves the file. Dimension reduction is quadratic. When a form demands 20 KB and quality alone cannot get there, cutting dimensions does not just help, it compounds: each step down in pixels multiplies the savings of whatever quality setting you then apply. This is also why the tool offers resizing as a toggle rather than a fixed behavior — for a 100 KB target it usually never fires, but for 20 KB it is the difference between success and a file that will not fit at any quality above 30.

One caveat so the math serves you instead of surprising you: file size does not scale perfectly with area because JPEG compresses each 8×8 block independently. An image whose dimensions are not multiples of 8 leaves edge blocks that compress differently. The effect is small — a few percent — but it is the reason the tool measures the actual output instead of predicting it. Trust the reported number, not the formula.

Every photo your phone takes carries a suitcase of metadata. EXIF — Exchangeable Image File Format, standardized in the 1990s by the camera industry — rides inside the JPEG file and records the camera model, the lens settings, the exact timestamp to the second, and very often GPS coordinates accurate to a few meters. On a typical smartphone photo this suitcase weighs 10 to 30 KB. On a 4 MB photo nobody cares. On a 100 KB target, it is a tenth to a third of your entire budget spent on data the form will never read.

Some of that metadata is actively useful — photographers want their shutter speeds preserved — but for a form upload it is dead weight, and the GPS portion is the part privacy people rightly complain about: upload a photo straight from your phone to a public listing and you may have published your home address alongside it. Camera orientation is stored as an EXIF tag too, which is the root of the sideways-photo problem portals are famous for: the pixels are stored rotated, the viewer corrects them using the tag, and any system that ignores the tag shows your passport photo lying on its side.

Re-encoding through the browser handles all of it at once. The canvas decode-and-encode pipeline reads only the pixels — everything EXIF carried is dropped, and the pixels are written in their displayed orientation, so the output is upright everywhere and carries no location history. For a 50 KB passport photo, this metadata stripping is not an optimization, it is a prerequisite: you cannot reliably hit small targets while towing 20 KB of invisible luggage. There is a checker on this site — the image size in KB checker — if you want to see how much a given file carries before and after.

Sooner or later the job stops being one photo. A class of forty students' registration photos. A company's onboarding batch. A wedding client's print order converted for a web gallery. The temptation is to find one quality setting that works and apply it to everything — and that is exactly the wrong instinct.

Two portraits shot minutes apart on the same phone can differ by a factor of three in raw file size. One has a plain wall behind the subject; the other has trees, and every leaf is high-frequency detail the entropy coder has to describe. Apply a single quality-70 encode to both and the plain one lands at 60 KB while the leafy one lands at 210 KB. If the form wants 'under 100 KB', you have just failed half the batch in a way you will not notice until the portal rejects file number seventeen.

The fix is to target the byte count, not the quality. That is what this tool does per image: load, compress at the same KB target, download, Reset, next. Your last target sticks, so a batch of forty photos at 100 KB is about a minute and a half of drag-and-drop. Each image gets its own binary search and its own quality, and every output lands under the ceiling — the consistent thing across the batch is the byte budget, which is the only thing the portal actually measures.

For larger batches, a filing habit pays for itself: keep the originals in one folder, the compressed outputs in another, and name the outputs with the target — photo-100kb-01.jpg and so on. Portals change their limits more often than they announce it, and a 50 KB variant of a 100 KB batch is a five-second re-run from the originals. It is a slow, quality-bleeding multi-pass job if you only kept the compressed copies.

If compressing images by hand feels crude, that is because at scale the web solved it a different way. Every major site you visit — news publishers, online stores, social platforms — does not store one image per picture. It stores a dozen, at different widths, generated automatically. Then, when your browser requests the photo, it declares its actual layout size and screen density, and the server hands over the smallest variant that looks sharp. That machinery is why a news article with twenty photographs still loads in a couple of seconds on a phone.

Two pieces make it work. The first is the srcset attribute in HTML, which lets a page list several files for the same picture — a 400-pixel version for a phone column, an 800-pixel version for a tablet, a 1600-pixel version for a desktop hero — and the browser picks. The second is the image CDN: a server like Cloudflare's or Akamai's, sitting close to the visitor, that resizes and re-encodes on the fly, often converting to WebP or AVIF for another 20 to 30 percent on top of JPEG. Netflix published research showing their per-title encoding saves around 20 percent of bandwidth just by tailoring compression to the content; image CDNs apply the same idea to every photo on every site.

The reason this matters to you is calibration: those pipelines aim for quality levels very much like the ones this tool finds. A hero image served to a phone at quality 75 and 800 pixels wide looks identical to the 300 KB original — because it effectively is the original, minus everything a 5-inch screen cannot display. When you compress a photo to 100 KB for a form, you are doing manually, in one pass, exactly what the web's infrastructure does automatically to nearly every image you look at. The JPEG you download is not a degraded copy; it is the size the image would have been if a competent pipeline had touched it.

The other place kilobyte discipline pays off is email. Gmail, Outlook, and Yahoo all cap total message size at 25 MB — a number inherited from old mail-server conventions, not from any modern storage reality. Attach three photos from a recent phone and you are at 12 MB before the message says a word; attach ten and the mail bounces, usually after a confusing delay, with an error from a server you have never heard of.

What makes it worse is that attachments do not count at their file size. Email was designed in an era when mail systems could only carry plain text, so attachments are encoded as base64 — every three bytes of binary data become four text characters. That is a 33 percent overhead, and combined with MIME framing the real-world inflation is about 37 percent: a 6 MB photo actually consumes roughly 8.2 MB of your 25 MB allowance. Three such photos plus a PDF and a signature image, and the wall arrives faster than the arithmetic suggests.

Compressing before attaching is the whole fix, and the numbers are lopsided in your favor. A photo taken for an email is almost always viewed on a screen at a fraction of its native resolution — resizing the long edge to 1600 pixels and compressing to 150–200 KB makes it perfectly readable and shrinks the mail from 12 MB to under 2 MB. For the same reason, base64-encoded images inside HTML email are the worst case of all: they cannot be cached separately, they count fully against the size, and many clients clip messages beyond roughly 100 KB of body content, so embedding photos in the email body rather than attaching them is a mistake worth unlearning. Attach small JPEGs; never embed big ones.

Here is a mistake that costs people more bytes than any quality setting ever will: saving photographs, or anything photographic, as PNG. PNG arrived in 1996 as a lossless format — it stores every pixel exactly, built on the DEFLATE compression also used in ZIP files. For screenshots, diagrams, and images with flat colors and sharp text, losslessness is ideal and PNG compresses them brilliantly. For photographs it is a disaster: the sensor noise and subtle color gradients that make a photo look real are precisely the patterns lossless encoding cannot summarize, so it describes every pixel individually.

The gap is enormous and consistent. A 2 MB photo saved as PNG weighs 8 to 12 MB. A UI screenshot with flat backgrounds converts the other direction — PNG to JPEG — and there the numbers flip: JPEG's lossy quantization eats flat areas almost for free, and a screenshot that weighed 900 KB as PNG re-encodes at 150–300 KB as JPEG, a saving of 60 to 80 percent, usually with no visible difference at normal viewing size.

So the decision rule has exactly two branches. Photographs and document scans: JPEG, always — PNG buys you nothing there and costs five to ten times the bytes. Screenshots, logos, diagrams, anything with text you need pixel-crisp: stay PNG, because JPEG's 8×8 blocks add faint ringing halos around letter strokes. One exception worth knowing: screenshots that contain a photo, like a product page capture with lifestyle imagery — those sit in between, and zooming to 200 percent on the text tells you which way to go. If the letters are crisp and the photo is the bulk of the area, JPEG usually still wins on bytes and loses nothing that matters.

If your target is a hard KB number and the source is a PNG photo, converting to JPEG is not step one — it is the whole game. Everything the quality slider does afterward happens on a file already five times smaller than where you started.