HomeGuides › Why files get large

Why is my image file so large?

Compressing blindly is guessing. Almost every oversized image traces back to one of six causes, and the right fix depends entirely on which one you have.

Updated 28 August 2026 · 11 min read

Nothing about a screenshot of an email feels like it should weigh 8 MB. There is no scenery in it, no faces, hardly any colour — a white background, a few hundred words of black text, perhaps a button. And yet there it is, too big to attach, sitting on your desktop like a piece of furniture that will not fit through the door.

File size is not a measure of how interesting a picture is. It is a measure of how much work an encoder had to do to write down one particular grid of pixels, in one particular format, at one particular setting. A photograph of a blank wall taken at 48 megapixels can easily be larger than a busy street scene at 2. So the useful question is not how do I make this smaller — that is a button, and you can find it in ten seconds. The useful question is which of the handful of things that inflate image files is happening to mine, because each one has a different fix, and applying the wrong fix costs you quality for nothing.

There are roughly six causes. Most oversized files have two of them at once.

Diagnose before you treat

Before touching a slider, look at three things: the pixel dimensions, the file extension, and whether the image came from a camera or a screen. Those three facts narrow the cause down almost every time.

SymptomLikely causeThe fix that matches it
A photo from your phone is 6–12 MB Sheer resolution — 12 megapixels or more Resize the long edge to what the job needs
A photograph saved as PNG is enormous Lossless format holding lossy content Save as JPG or WebP instead
Screenshot of text is several MB and looks fuzzy round the letters JPEG applied to hard edges Save as PNG or WebP, not JPG
File is large but looks flawless even zoomed in Quality set at or near 100 Re-encode from the original at around 80–85
A small, plain image is stubbornly bigger than it should be Embedded preview, metadata or colour profile Inspect the file, then strip what you do not need
A “1920 × 1080” screenshot is really 3840 × 2160 High-density display capturing at 2× Halve the dimensions before sending
File grew after editing, and looks worse than before Repeated lossy re-saves Go back to the original and edit once

Cause one: far more pixels than the job needs

This is the single most common answer, and the least dramatic. Phone cameras shoot 12, 48 or more megapixels because sensor resolution is a number that sells phones. Almost nothing you do with the resulting picture requires that many pixels. A photo attached to an email is looked at on a screen. A profile picture ends up a few hundred pixels across. A product listing is displayed at maybe 1200 px wide. In every one of those cases the extra pixels are decoded, scaled down and thrown away by the device showing them.

What makes resolution such a powerful dial is that it is quadratic, not linear. Pixel count is width multiplied by height, so halving both halves nothing — it quarters the total. A 4000 × 3000 image holds 12 million pixels. At 2000 × 1500 it holds 3 million. Cut it once more, to 1000 × 750, and you are down to 750 thousand — about one-sixteenth of where you started. File size does not fall by exactly the same ratio, because compression is content-dependent, but it falls steeply and in the same direction.

The corollary is worth stating plainly: if a file is far too large and quality adjustments are not getting you there, the image is almost certainly being asked to stay bigger than it needs to be. Resizing is the blunt instrument that actually works.

A rule of thumb for the long edge: around 2000 px covers almost any on-screen use including a full-width banner on a large monitor. Around 1200 px is plenty for a document, a listing or an email attachment. Below 800 px you are into thumbnails and avatars. Printing is the exception — paper resolves detail that screens do not, so keep the pixels if the picture is going to a printer.

Cause two: the format does not match the content

Formats are not interchangeable containers. Each one makes an assumption about what is inside it, and gets efficient by exploiting that assumption. Break the assumption and the file balloons.

PNG is lossless. It stores every pixel exactly as it was, and reconstructs the image byte-for-byte. It compresses by finding repetition — runs of identical colour, rows that resemble the row above. Give it a logo with twelve flat colours, a chart, a diagram or a screenshot of a settings panel, and it will find repetition everywhere and produce a tiny file. Give it a photograph, where two hundred thousand pixels are all slightly different shades of the same green, and there is nothing to exploit. It stores all of them. Converting a 3 MB photograph to PNG routinely yields a file several times larger, and it looks no better — you have preserved detail nobody could see and paid for it in bytes.

JPEG assumes photographs. It works by discarding the fine variations human vision is poor at noticing, and it is very good at that. But its whole model is built around gradual change: skin tones, skies, blurred backgrounds. Text is the opposite. A letterform is a hard black edge against pure white, and JPEG has no efficient way to describe a sudden jump. So it approximates, and the approximation shows up as faint grey haze and coloured speckles hugging every character — the fringing you have probably seen on a screenshot someone sent through a compressing chat app. Worse, those hard edges are expensive: the encoder spends bytes fighting them. A screenshot of text saved as JPG is often both larger and uglier than the same screenshot saved as PNG.

So the rule is content-shaped, not preference-shaped: photographs and anything with soft gradients want a lossy photographic format. Screenshots, diagrams, line art, text and flat colour want a lossless one. WebP is unusual in offering both modes, which is why it wins so often; the comparison is laid out in more detail in WebP vs JPG vs PNG vs AVIF. And if the reason you chose PNG was transparency rather than quality, that is a genuine constraint with its own trade-offs, covered in PNG vs JPG for transparency.

Compress or convert in your browser → Resize, change format and set a quality level in one pass — or give it a maximum file size and let it search for the best quality that fits. The file is processed on your own device and never uploaded.

Cause three: quality set higher than anyone can see

Every lossy encoder takes a quality number, and the number is not a percentage of anything. It is a position on an internal scale, and the relationship between that position and the resulting file size is steep and uneven rather than proportional.

The expensive end is the top. Going from quality 90 to quality 100 asks the encoder to preserve detail that is, for practical purposes, noise — sensor grain, single-pixel variations, the exact shade of one leaf. The cost of describing all of that is large, and the visible benefit on a screen is close to zero. Meanwhile the drop from 95 to 85 can roughly halve a file while changing almost nothing you would notice without flicking between the two at full zoom. Further down the scale the curve flattens the other way: going from 50 to 40 saves comparatively little and looks distinctly worse.

This is why software defaults matter so much. Plenty of applications save at maximum quality unless told otherwise, on the reasonable assumption that you would rather have a big file than a damaged one. Photo apps that offer “maximum quality” or “100%” on export are handing you a file two or three times larger than the same picture at 85 with no visible gain. If a file is large but looks pristine even when you zoom right in, this is your cause.

Because the curve is uneven and content-dependent, guessing a quality number to hit a specific size is a poor strategy. Searching for it is the reliable method, and it is described step by step in how to compress an image to an exact file size.

Cause four: everything in the file that is not the picture

An image file contains more than pixels. A photograph out of a phone typically carries EXIF metadata: camera model, lens, exposure settings, orientation, the date, the software that touched it and often the GPS coordinates where it was taken. It may carry an embedded ICC colour profile describing the colour space, so other devices can reproduce the tones correctly. And it may carry an embedded preview thumbnail — a small, complete, separately-encoded copy of the image, kept so that file browsers and cameras can show it instantly.

Keep the proportions honest here. Metadata itself is typically a few kilobytes; it will not explain an 8 MB file. Colour profiles are usually small too, though some are considerably fatter than others. The embedded preview is the one that can surprise you, because it is a whole second image. On a large photograph it is a rounding error. On a small, heavily compressed image — the kind you have already squeezed down for a form — the preview can be a meaningful share of what is left, which is why a file sometimes refuses to drop below a stubborn floor no matter what quality you choose.

Stripping extras is worth doing at a tight boundary, and worth doing anyway for the GPS coordinates you probably did not mean to publish. Just do not expect it to rescue a genuinely oversized file. The right move is to look before you cut.

See what is actually in your file → Read the EXIF fields, colour profile and location data a photo is carrying, then save a clean copy without them. Nothing leaves your browser.

Cause five: screenshots on a high-density display

This one catches almost everybody, because the operating system is quietly lying to you in a helpful way. A modern laptop or phone reports its screen in logical points rather than physical pixels. Your display says it is 1920 × 1080, and every window, menu and font is laid out on that grid — but the panel underneath has two physical pixels for every logical one in each direction, so it is really painting 3840 × 2160.

Screenshot tools capture physical pixels, because that is what is genuinely on the screen. So a full-screen capture that you think of as a 1080p image — two million pixels — arrives at 3840 × 2160 instead: twice the width, twice the height, four times the pixel count, and over eight million pixels in all. Some phones go further than 2×. This is why a screenshot of a text document — a picture with almost no visual complexity — can arrive at several megabytes, and why the number feels so absurd relative to the content.

The fix is simply to halve the dimensions, which returns the image to the size it appeared on your screen and loses nothing you were actually looking at. Do that before any format decision, because it removes three-quarters of the pixels the encoder would otherwise have to describe. And keep the format lossless while you are at it — a screenshot is the exact content JPEG handles worst.

Cause six: the file has been saved too many times

Lossy compression is not a filter you apply to an image; it is a lossy translation of it. Translate, then translate the translation, and errors accumulate. Each pass through a JPEG encoder discards a little more information — but the second and later passes have an extra problem, which is that they are no longer encoding a photograph. They are encoding a photograph plus the previous pass's artefacts, and those artefacts are hard-edged blocky patterns of exactly the kind JPEG is bad at describing efficiently.

The practical result is the counter-intuitive one: a file that has been opened, tweaked and re-saved half a dozen times can be larger than the original while looking noticeably worse. You are spending bytes to describe damage. If a screenshot has been through a chat app, a document, a download and a crop tool, it may well be carrying four generations of that.

There is a well-meaning mistake that makes it permanent: saving a JPEG as a PNG “to preserve quality”. PNG is lossless, so it faithfully preserves whatever it is given — including every artefact already baked into the JPEG. Nothing is recovered. You have taken a damaged image and stored it in a format that cannot compress photographic content, so you end up with the original's flaws at several times the file size. Lossless preservation only preserves; it does not repair.

The discipline that avoids all of this is to keep the original untouched, do your edits in one session, and export once at the setting you actually want. If you need three different sizes, make all three from the original rather than from each other.

Common questions

Does changing DPI make the file smaller? No. DPI is a printing instruction stored in the file header — a note that says print me this big. Changing it from 300 to 72 removes no pixels and saves essentially nothing. Only a resize changes the pixel count.

Why is my screenshot bigger than my holiday photo? Usually two causes stacking: the screenshot was captured at 2× on a high-density display, and it was saved as PNG at that full resolution. Halve the dimensions first; the format is probably the right one if the image is mostly text.

Why did the file get bigger after I compressed it? Either the original was already compressed harder than the setting you chose, so you re-encoded it upward, or you converted a photograph to PNG. Both make the file larger and the picture slightly worse.

Does cropping reliably shrink a file? Not reliably. Cropping removes pixels, which helps, but you might have cropped away the smooth easily-compressed sky and kept the detailed, expensive foliage. Content matters as much as area.

Is there any reason to keep a 48-megapixel original? Yes — as an archive, and if you may want to print large or crop in heavily later. Keep the original and send a resized copy. The mistake is treating the archive file as the everyday file.

Which single change usually helps most? Reducing the dimensions, because the effect is quadratic and it makes every other setting cheaper. Fix the resolution first, then choose a format that suits the content, then set quality around 80–85.

Keep reading