Compress Image to 100KB

Set the compressor's target to roughly 100KB, pick JPEG for photos or WebP for a smaller file at the same quality, and let quality drop before dimensions do. Everything runs in your browser — the image is decoded, re-encoded and downloaded locally, and no copy is ever uploaded.

Local-only

Just want the tool? Open Compress ImageHit a file size, or pick a quality and see the cost.Open tool

A 100KB ceiling is one of the most common upload gates on the web: government portals, job application forms, conference submission systems and university portals all impose it, and almost nobody's camera produces a file that small by default. A 12-megapixel phone photo starts at 3–5MB, so the job is never "make it a bit smaller" — it is a 30–50× reduction, and that means choosing which kind of loss you can live with.

The Image Compressor on this site does the whole job locally: your photo is decoded to pixels in the browser tab, re-encoded at the settings you choose, and handed back as a download. There is no upload step to trust, no queue to wait in, and no copy of your image on anyone else's disk — because there is no server involved at any point.

This page is the recipe for hitting a specific number. It explains the two dials that matter — dimensions and quality — the order to sacrifice them in, and the format choice that changes the whole equation. The short version: shrink pixels first, then trade quality in small steps, and prefer WebP when the receiving system accepts it.

Everything below happens in the Image Compressor — open it in a second tab and follow along.

If the JPEG-versus-WebP decision is new territory, the image formats guide explains what each format trades away.

The two dials: dimensions first, quality second

File size scales roughly with pixel count times quality. Pixel count is quadratic — halving both width and height removes 75% of the pixels — while quality is a gentler curve: the step from quality 80 to 60 often halves the bytes for a change few eyes catch on a photo. So the recipe is ordered: resize to the largest dimensions the receiving system actually needs, and only then walk quality down.

Portal needs 1024px wide? Resize to 1024 first. A 4000px image compressed to 100KB wastes detail on pixels the form will never show.
Walk quality in steps of 10 from 80 downward, re-encoding each time, and stop at the first step under the limit — the last step you skipped is quality you keep.
Below quality 40, JPEG artefacts smear edges and text; if you are down there, go back and remove pixels instead.

Format choice changes the maths

For the same visual quality, WebP typically lands 25–35% smaller than JPEG, which turns a barely-passing 100KB encode into a comfortable 70KB one. PNG is the wrong tool for photographs — it is lossless, so a photo PNG is often ten times the JPEG — but it is the right tool for screenshots and diagrams with flat colour and sharp edges. AVIF beats WebP in many cases but browser and portal support still varies, so treat it as a bonus format rather than the plan.

Source material	Pick	Why
Photographs	JPEG or WebP	Lossy formats tuned for continuous tones
Screenshots, diagrams	PNG or WebP	Flat colour compresses cleanly without artefacts
Photos + portal allows WebP	WebP at q≈70	Same look, roughly 30% fewer bytes than JPEG

The 100KB recipe, step by step

Open the compressor, drop the image, and set the longest edge to what the portal actually requires — 1024px and 1600px are the common ceilings. Encode once at quality 75 and check the size. If it is over, step quality down by 10 and repeat; if it is dramatically under (say 60KB), step quality up once, because head-room you leave behind is quality you gave away for nothing.

Two honest caveats. Re-encoding is lossy by definition — the downloaded file is a new JPEG/WebP derived from your original, so keep the original for the archive and treat the output as the submission copy. And metadata is not preserved: EXIF including GPS coordinates is dropped by the re-encode, which for a submission form is usually exactly what you want, and the metadata-removal page below covers that topic on its own.

When 100KB is genuinely not enough

Some images cannot survive 100KB without visible damage: a scanned A4 document at readable resolution, a group photo where faces must stay sharp, an image with fine text. In those cases the honest options are outside the encoder — ask the receiving system whether PDF is accepted (text-heavy scans compress far better in PDF), whether fewer pixels are truly required, or whether the limit exists to protect their storage rather than their process, in which case a polite enquiry sometimes unlocks a larger allowance. No encoder setting rescues an image whose information genuinely needs more room.

Frequently asked questions

Is my photo uploaded when I compress it here?

No. The compressor decodes and re-encodes the image inside your browser tab using the Canvas and encoding APIs that ship with the browser itself. There is no upload endpoint, and the Content-Security-Policy blocks outbound connections. Watching the Network tab while you compress shows zero requests carrying your image.

What quality setting hits 100KB most often?

For a 1024px-wide JPEG of a typical photo, quality 65–75 usually lands between 60 and 120KB. There is no universal number — scenes with lots of fine texture (foliage, crowds) produce larger files than clean gradients — which is why the recipe is iterate-by-ten rather than one magic setting.

Why is my PNG photograph so much larger than the same image as JPEG?

PNG is a lossless format: it stores every pixel change exactly, and photographs are full of tiny changes. For photos the file is often 5–10× the JPEG. PNG shines on screenshots, logos and diagrams — flat colour areas and hard edges — where it is frequently smaller *and* sharper than a lossy encode.

Does compressing remove EXIF and location data?

Yes — re-encoding through the canvas drops EXIF metadata including GPS coordinates, camera model and timestamps. If your goal is specifically metadata removal at original quality, the metadata-removal tool handles that directly; if you are compressing anyway, the clean file comes out as a side effect.

Can I compress to exactly 100KB, not just under it?

The compressor targets a ceiling, not an exact byte count — encoders are not deterministic enough to promise 100,000 bytes on the nose, and portals check "at most", not "exactly". Get within 10–15% below the limit and you have the best quality the constraint allows.

Will compressing the same file twice hurt quality?

Yes — every lossy generation compounds. Compress from the original each time you need a different size, and keep the untouched original as your source of truth. If a portal rejects a file and asks for a smaller one, go back to the original and take a bigger quality step, rather than re-compressing the already-compressed copy.

ToolsByUs team · How we check our tools