Image File Size: The Actual KB/MB Budget for Every Use

A file's weight is what the destination cares about; its dimensions are what the viewer's eyes care about. They connect through the encoder — more pixels means more to store — but confusing them sends people down the wrong path: a photographer shrinking a 6000 px original to 900 px to hit a 1 MB email target is destroying a file for a problem the quality slider solved perfectly at full width. Dimensions serve display; quality serves weight.

The one situation where weight genuinely indicates dimensions: a file 10× the size of everything else in its slot is almost always an un-resized original. The web average image is 200-300 KB; a 4 MB hero is not 'high quality', it is an unprocessed export.

Websites you control: hero/LCP images target 100-200 KB on mobile-first thinking; secondary in-page images 60-120 KB; thumbnails and icons 5-30 KB. These numbers come from the Core Web Vitals math — 200 KB is roughly half a second on a good 4G connection, and every image on the page competes for the same budget.

Email: 1 MB per image is the safe practical number (message caps of 20-25 MB shared between everything, and some enterprise gateways drop over 10). Documents and application forms: whatever the form says, plus a margin — 2 MB requested means deliver under 1.5; a rejected upload costs the deadline you spent arguing about it.

Instagram and social platforms: irrelevant to control — they re-encode to their own targets; your job is delivering the right dimensions at high quality (the social resize guide), not chasing a KB figure. Chat apps: same — WhatsApp photos are recompressed to ~100-200 KB regardless of what you sent, unless sent as a document, where your file weight becomes the recipient's download.

Print: no weight budget at all. A 300 MB TIFF for a magazine page is normal and correct; the pixel budget (300 ppi at final size) is the only number that matters. Print shops' complaints about 500 KB 'photos' are complaints about pixels, not bytes.

File weight ≈ pixels × information density × format efficiency. Pixels you set with the resizer; information density is what the image contains — a flat-colour logo is nearly free to encode and a forest photograph is expensive, which is why your 'same settings' batch produced wildly different sizes; format efficiency is the encoder's cleverness, roughly: PNG 3-5× JPEG, WebP ~0.7× JPEG, AVIF ~0.5× JPEG at equal visual quality.

The practical consequence: a target file size is a property of the content, not of the settings. A quality slider does not promise '200 KB'; it promises 'this much visible loss'. Hitting a hard byte target is the tool that iterates quality until the math lands — or knowing that the forest photo at the quality that looks right will simply weigh more, and the right answer is fewer pixels or a better format.

Step one: set dimensions to what the destination actually renders — display width ×2, or the form's stated pixel maximum. Compress to the format the destination accepts at a sane quality (85) with the image compressor, and measure. Half the jobs are done: a 1200 × 800 photo at quality 85 is a 150-250 KB file.

Step two: still heavy, drop quality in 5-point steps with the 100% zoom edge check — 80, 75 — and only then consider trading pixels, because a final 20% of dimensions costs the eye less than the first 10% of aggressive JPEG. Reaching under 1 MB from a multi-megabyte camera original takes two sliders and ten seconds; the reason the task feels mysterious is people start at the wrong one.

And the order of operations that prevents double loss: resize and re-encode from the largest clean original, once, into the final file. A chain of compressions on already-compressed JPEGs is how mush happens — the same target reached from the original in one pass looks visibly better.

A useful gut calibration: a typical web photograph at correct dimensions is 100-300 KB; anything over 1 MB for a screen image is unprocessed. A scanned document page is 100-300 KB in grayscale and four times that in colour. A product photo for a marketplace is 500 KB-2 MB because they will accept the pixels and re-encode anyway. A screenshot at native retina resolution is 1-5 MB as PNG and converting to WebP cuts it by 70% without touching legibility. When a file sits far outside its lane, something skipped the two-step — usually step one.