Last month I was helping my mother upload a photo of my sister for an exam registration on her phone, and the page asked for a one-inch photo, JPG, under 500KB. She took the shot and picked the one already in her album: 3024×4032, 6.1MB, and the red warning came up three times: File size exceeds the limit. I kept cropping on the phone and it still would not go through. Only when I moved it to the computer did I work out where the problem was: I had been adjusting the crop box, when the file size is actually decided by the total pixel count and the encoding quality, not by the display size. After that I went through every image on my own site as well, and the first-screen load time dropped from 3.4 seconds to 1.9. This piece is about the conclusions from both.
1. What decides the size of a photo
Broken down as a problem, an image being too big is really three layers:
- Total pixel count: 4032×3024 is 12.2 million pixels, 1600×1200 is 1.92 million, more than six times fewer. Leave this layer alone and there is a hard limit to what further compression can do.
- Encoding and quality: at the same pixel count, JPG quality 95 and quality 75 can differ three to five times in size; the same frame saved as PNG is usually much larger than JPG, because PNG's lossless algorithm handles the continuous gradients of a photo badly.
- Attached data: EXIF, capture time, camera model, GPS coordinates, embedded thumbnail. In a phone original this is often tens to over a hundred KB, and it is the part most likely to leak something.
Figures I have measured myself: JPG photos straight from a phone run 2-4MB; a 1440×900 desktop screenshot saved as PNG is about 1.1MB, and the same image as JPG at quality 80 drops to around 180KB; a standard one-inch photo at 295×413 pixels is usually 40-70KB at JPG quality 85. So getting my mother's 6.1MB photo down to 500KB was never a matter of compressing it slightly.
2. Shrink the dimensions first, then the quality; the wrong order wastes the effort
The usual mistake is to take a 4000-pixel-wide image and start lowering quality, only scraping under the limit at 40% with the text edges already a mush. The right way is to bring the long edge down to the pixels you actually need for the purpose, then finish at a moderate quality. The settings I use:
| Use | Long edge | Quality | Typical result |
|---|---|---|---|
| Registration or ID photo upload (295×413 and similar) | Whatever the platform requires | JPG 80-90 | Tens of KB, far under the 500KB limit |
| Blog images, product pages | 1600-2000 | 75-85 | 150-350KB, no visible loss |
| Large above-the-fold image | 1200-1600 | 70-80 | Pair with lazy loading to keep LCP down |
| Chat logs, document screenshots | Keep the original pixels | Lossless PNG or WebP | Prefer lossless; text edges must not smear |
| Product shots sent to a client | Whatever they ask for | 85-92 | Keep the original and save a compressed copy |
For that 6.1MB photo I ended up at a 1200-pixel long edge and quality 82, which came out at 240KB, still enough to print a one-inch layout. What did the work was the resizing step, not the quality slider.
3. Lossless, lossy, and choosing a format
Lossless reorganises the data without changing a single pixel; lossy allows some information the eye barely notices to be discarded. The choice depends on the content, not on which one is more advanced:
| Format | Transparency | Good at | Weak at |
|---|---|---|---|
| JPG | No | Photos, gradients, size-sensitive work | Colour banding at text edges; repeated saves accumulate loss |
| PNG | Yes | Screenshots, icons, line art, anything needing transparency | Large for photo-like content |
| WebP | Yes | Web images, smaller at equal quality, can hold animation | Will not open in very old environments, so keep a JPG fallback |
Lossy compression carries a hidden cost: every re-save and export in a lossy format adds another layer of loss. So my habit is to keep the original forever and let compression produce only copies. When I need different settings I rerun from the original instead of compressing the compressed result.
4. The process I actually use
- Decide first whether this is a dimension problem or an encoding problem: view the image at 100% and look at the detail. If it is 4000 pixels wide and the page shows it 800 pixels wide, the answer is in the dimensions.
- For oversized images, resize by pixels or percentage with Image Resizer, ticking the aspect ratio lock so nothing stretches. This step takes PNG, JPG, WebP, GIF and BMP.
- Then run Image Compressor in batch: drop a dozen files at once, set quality anywhere from 10% to 100%, and compare the before and after size and ratio right on the page. The effect is immediate; I usually start at 80 and try two steps down.
- Look separately at any PNG that needs an alpha channel and confirm it still has one; for screenshots, prefer the lossless setting.
- Rename the exported copies by date and put them back, leaving the originals alone. The whole process runs locally in the browser and nothing is uploaded, which matters for client material and ID photos.
5. Details that get overlooked
- GPS travels with the original: photos straight from an iPhone often carry latitude and longitude in EXIF, and sending the original in WeChat passes them along too. Before sending someone an ID photo, either remake it with a screenshot or strip the attached data on export.
- Platforms compress again: Weibo, WeChat and some e-commerce backends compress your image a second time. An image already compressed hard gets worse in layers, so uploading it makes it blurrier still.
- Transparent backgrounds turn black or white in JPG: JPG has no alpha channel, so confirm the target format before compressing, or lay down a background colour first.
- HEIC and the iOS album: iPhones save HEIC by default and many web forms only accept JPG or PNG, so convert once before uploading.
- The first-screen budget: on my own site images are about sixty percent of the above-the-fold resources, and the LCP good threshold is 2.5 seconds. Optimising that one large image usually pays more than compressing the twenty small ones below it.
- GIF is the heavyweight: a GIF with many frames cannot be rescued by compression quality; cutting dimensions or frames is the only real fix.
6. Common questions
Q: The platform limits uploads to 500KB. Should I lower the quality or shrink the dimensions?
Shrink first. Halve the pixel dimensions and the size drops to roughly a quarter with almost no visible change; lowering quality alone often has to go to forty or fifty to pass, and the edges and skin degrade together.
Q: Does compression visibly hurt quality?
Lossless leaves pixels untouched, so nothing changes; lossy in the 75 to 85 range is usually indistinguishable on photo content. To judge, compare text edges and strands of hair at 100%, because those give it away first.
Q: What format should a screenshot use in a group chat?
PNG, or a lossless PNG compression. A screenshot is all hard-edged text and flat colour, and lossy compression produces colour banding at the letter edges that looks dirtier than the original.
Q: Will some people be unable to open WebP?
Mainstream browsers and systems of recent years all support it, and it can be used on the web directly. For an unspecified external audience, keeping JPG or PNG is safer.
Q: Does batch processing overwrite the originals?
My setup keeps originals in a separate read-only folder and writes compressed results as copies under a new name. Nothing that implies overwriting the original file should ever run on the source image.
Back to that 6.1MB photo. It was never compressed to the limit; at 1200 pixels, quality 82 and 240KB it passed review. The limit exists for people, not for image quality. Only two things about order are worth remembering: check whether the pixels are enough, then check whether the format and the setting are right. Everything else is a knob you can turn again.