Drop a file here, or choose one

You can get almost any photo under 500KB using the tool above: drop in your file, set the target to 500KB, and it re-encodes the image at the highest JPEG quality that still fits. This page covers what that target actually means and when it’s the right one to use.

Why 500KB specifically

500KB is one of the most common upload ceilings on the web, not because it’s a round number but because it’s roughly the largest file size that keeps page load times and email attachments reasonable while still preserving enough detail for a full-screen photo. You’ll see it as the cap on: job application portals, WordPress media uploads on shared hosting, many government and university document-upload forms (often paired with a 2MB cap for accompanying PDFs), and forum or classified-ad image uploads that predate today’s higher storage limits.

What actually changes in the file

JPEG compression works by throwing away information the human eye is bad at noticing: it averages color detail across small blocks (chroma subsampling) and discards high-frequency variation within each 8x8 pixel block (via the DCT quantization step) more aggressively as you lower the quality setting. At quality 90+, you’re removing sensor noise you’d never notice. By quality 60-70, fine texture — hair strands, fabric weave, distant foliage — starts to simplify into soft blotches, and you may start to see faint 8x8 blocking in flat gradient areas like skies. Below quality 50, blocking and “mosquito noise” around hard edges become visible even at normal viewing size.

A typical modern phone photo (4000x3000px, 3-8MB out of the camera) has so much redundant data that hitting 500KB usually only requires quality 75-85 — well above where artifacts become visible. An already-small or already-compressed image asked to shrink further will need a much lower quality setting and will show it.

The re-encoding trap

If a photo has already passed through JPEG compression once — say, it was posted to social media, downloaded, and now you’re compressing it again for a different upload — you’re compounding two separate rounds of lossy encoding. The second pass can’t undo the first pass’s block boundaries; it just adds its own on top, often at a different 8x8 grid alignment, which is what causes the double-compressed “smeared” look. When possible, always compress from the original camera file rather than a copy that’s already been through a compressor.

When to resize instead of (or in addition to) compressing

If you know the image only needs to display at, say, 1200px wide, resizing to those dimensions first will get you well under 500KB at a much higher visual quality than compressing the full-resolution image down to the same file size. Compression alone is the right call when the receiving system checks pixel dimensions (ID photo uploads, some print services) and you need to preserve them exactly.

Frequently asked questions

Will compressing to 500KB make my photo blurry?
Not usually. A typical 12-24 megapixel phone photo saved straight out of the camera is 3-8MB, and almost all of that is redundant data a JPEG encoder can discard with no visible difference. Getting to 500KB from a source that large usually lands around quality 75-85, which is still visually lossless on a screen. You'll only see softening or blocky artifacts if your original was already small (under 1MB) and you're compressing it a second time.
Why do some of my photos get smaller than others at the same target size?
JPEG compression is content-dependent. A photo of a plain wall, sky, or a document with lots of flat color compresses to a tiny file easily. A photo of grass, water, fabric texture, or a crowd has high-frequency detail everywhere, so the encoder needs a higher quality setting — and therefore more bits — to avoid visible blockiness at the same perceived quality. Two 500KB outputs from different source photos can look very different in sharpness because of this.
500KB or 512KB — which one is 'under 500KB'?
File size units are ambiguous in casual use. '500KB' means 500,000 bytes (decimal) on some systems and 512,000 bytes (binary) on others. Windows Explorer reports the binary figure; macOS Finder has reported the decimal one since Mac OS X 10.6. Upload forms rarely say which they enforce. This tool deliberately targets the decimal figure, 500,000 bytes, because it's the smaller of the two — the output stays under a limit enforced either way. Aiming for 512,000 bytes would pass a binary-limit form but get rejected by a decimal-limit one.
Should I resize the image too, or just compress it?
If the photo is going somewhere with a known display size — a product listing, an avatar, a blog thumbnail — resizing the dimensions down first gets you a smaller file at a higher visual quality than compression alone, because there are simply fewer pixels to encode. If you need to preserve the original resolution (for printing, or a photo ID upload that checks dimensions), compress only and don't resize.
Does this work on PNG files too?
You can feed a PNG in and it will be re-encoded as a compressed JPEG to hit the target, which works well for photos. It's the wrong tool for screenshots, logos, or graphics with flat colors and text, because JPEG's lossy compression introduces visible ringing artifacts around sharp edges that PNG doesn't have. For those, keep the PNG or convert to WebP instead.