← Back to BlogImage Resolution vs File Size: Which One Should You Change
2026-10-08
Lowering resolution and shrinking a file get talked about as if they were one action, which is where bad decisions start. Resolution counts how many pixels the image has across and down. File size counts how many bytes those pixels take to store. Higher resolution usually means a bigger file, but there is no fixed ratio between them: a 4000x3000 screenshot of a flat colour can be 200KB, while a 1200x900 close-up of leaves can pass 1MB. Before you try to make a file smaller, work out which of the two is holding the size up.
Resolution governs the pixel count
Resolution is a geometric quantity and has nothing to do with the codec. It decides how many cells the picture is built from, and therefore the most those cells can weigh.
- 4000x3000 is 12 million pixels, and every one of them takes space
- Dropping to 2000x1500 quarters the pixel count, and the size ceiling drops by roughly the same factor
- It does not reverse. Detail lost to resampling cannot be recovered by any tool
- Print works to a floor of about 300 pixels per inch, and below that you see grain
- On the web, what matters is display width. A 1600 pixel image in an 800 pixel slot ships twice what anyone can see
File size governs how those pixels are stored
The same pixel count can produce wildly different sizes, and the difference comes from the codec and from what is in the frame.
- Lossy formats such as JPEG and WebP discard detail the eye tends to miss
- PNG compression is lossless and removes statistical redundancy, giving byte-identical output after decoding
- At the same pixel count, busier images weigh more. Leaves, hair and sensor noise resist compression
- Flat colour, gradients and empty sky compress well, and a plain screenshot can land under 100KB
- Metadata, embedded previews and an alpha channel add weight without showing up in the picture
Four sets of numbers from one photo
These come from a 4000x3000 phone photo. Treat them as typical magnitudes rather than exact figures for your own files.
- Straight from the camera at 4000x3000: about 4.2MB
- Resized only, to 1600x1200: about 480KB, with no visible sharpness change at normal viewing size
- Compressed only, quality 75, resolution untouched: about 1.3MB, all detail intact
- Resized first, then compressed once: about 190KB, which is what most pages actually ship
- Compressed three times at quality 60: about 900KB, larger and worse than a single pass
The last two lines settle it. Resize once then compress once is the cheap path, and compressing the same file repeatedly costs the most.
Work backwards from where the image ends up
- Web pages: resize to roughly twice the display width, then compress once
- Email attachments and upload caps: resize first, since compression alone rarely reaches the limit
- Screenshots with text: keep the resolution and use PNG, because resampling turns text edges to mush
- Print: leave resolution alone and save on encoding and format instead
- Archiving: only touch derived copies and keep the original where it is
Related walks through /blog/resize-and-compress-image, /blog/compress-jpg-under-100kb and /blog/how-webp-compression-works.
FAQ
Does higher resolution always mean a bigger file?
No. The pixel count sets a ceiling, not the outcome. Actual size depends on how much detail the picture holds and how it is encoded, and at the same resolution a flat screenshot and a frame full of leaves can differ tenfold.
Can I shrink a file without changing resolution?
Yes, within limits. Compression removes redundancy while keeping every pixel, which usually saves 30 to 70 percent. Hitting a hard cap like 100KB generally needs a resize first.
Why did halving the resolution only cut the size by 30 percent?
Because pixels are not the only thing in there. Metadata, embedded previews and an alpha channel take space too, and one compression pass after the resize usually removes another half.
Should I drop resolution to save space on print files?
No. Print sizes need around 300 pixels per inch, and going under that shows grain. Save on encoding and format instead.