Resizing vs Compressing Images

Two different jobs

Almost every "my image is too big" problem is really a confusion between two operations that both make files smaller in completely different ways.

Resizing changes the pixel dimensions. A photo that is 4000 pixels wide becomes 1200 pixels wide, and the pixels beyond that are gone. This is a permanent, structural change to how much information the image contains.

Compressing keeps every pixel but stores them more cheaply, throwing away detail the eye is unlikely to notice. The image still has the same dimensions; it just takes fewer bytes to describe.

The practical consequence is important: resizing usually saves far more than compressing, because file size scales roughly with the number of pixels, and pixel count scales with the square of the dimensions. Halving both width and height leaves you a quarter of the pixels. Squeezing quality on a 4000-pixel photo destined for a 600-pixel slot is fixing the wrong problem — resize it first, then compress what remains.

How lossy compression actually works

JPEG's quality slider is not a simple "amount of detail" dial, and understanding roughly what it does explains its odd behaviour. The encoder splits the image into 8×8 blocks of pixels and converts each block from raw colour values into a set of frequency coefficients — a description of how the block varies, from broad flat tone up to fine detail.

It then quantises those coefficients: divides them by a table of numbers and rounds. The quality setting scales that table. High quality means small divisors and little rounding; low quality means large divisors, and many of the fine-detail coefficients round away to zero entirely. Because zeros compress extremely well, the file shrinks dramatically.

This is why JPEG artefacts look the way they do. The blocky 8×8 squares that appear in heavily compressed images are literally the encoding blocks becoming visible once too much variation within them has been discarded. The coloured fringing around sharp edges — text especially — happens because a hard edge needs high-frequency detail to describe, and that is exactly what quantisation removes first.

It also explains the crucial rule: lossy compression is not reversible, and it compounds. Every time you save a JPEG you quantise again, and the losses accumulate. Editing a JPEG, saving, reopening, editing and saving again visibly degrades it. Always work from the original and export once.

Which quality setting to use

The returns are steeply non-linear. Going from 100 to 80 typically cuts the file by more than half with essentially no visible change; going from 80 to 60 saves much less and costs noticeably more. That is why 80 keeps being recommended — it sits right at the knee of the curve.

Content matters too. Photographs of natural scenes compress beautifully because they are full of gradual variation. Images with large flat areas and hard edges — screenshots, diagrams, text — compress badly in JPEG and look bad doing it, which is the clearest signal that you should be using PNG instead.

A related quirk explains why the same quality number gives wildly different file sizes on different pictures. Quality sets how aggressively detail is discarded, not what the final size will be, so a busy photograph of foliage at quality 80 can be several times larger than a portrait against a plain backdrop at the same setting. If you are working to a hard file-size limit, there is no substitute for exporting and checking — no quality value guarantees a size.

Choosing a format

JPG is the right default for photographs. It is lossy, universally supported, and its compression model is designed around exactly the kind of continuous tonal variation photographs contain. It has no transparency, which is why exporting a transparent PNG to JPG gives you a black or white background — the alpha channel simply does not exist in the format.

PNG is lossless and supports transparency. Every pixel comes back exactly as it went in, which makes it right for logos, icons, diagrams, and any screenshot containing text. The cost is size: a photograph saved as PNG is often five to ten times larger than a good JPG of the same picture, for no visible benefit.

WebP is the modern middle ground, typically producing files 25–35% smaller than JPG at comparable quality, and it supports both transparency and lossless mode. Browser support is now effectively universal, and the main remaining friction is that some older desktop software and a few social platforms still prefer a JPG upload.

Contain, cover and stretch

When your target dimensions have a different shape from your image, something has to give, and the three standard resolutions each sacrifice something different.

Contain fits the entire image inside the box. Nothing is cropped and the proportions are preserved, but one dimension ends up smaller than you asked for — a wide photo fitted into a square box will not fill the square's height.

Cover fills the box completely and crops whatever overflows. Proportions are preserved and you get exactly the dimensions requested, at the cost of losing the edges. This is what you almost always want for avatars, thumbnails and banners, and cropping from the centre is the usual default since subjects tend to be centred.

Stretch forces the exact dimensions by distorting the picture. It is almost never what you want, and the giveaway is faces that look subtly too wide or too narrow. The one legitimate use is when the source was already distorted and you are correcting it.

Sizing for the web

The single most common mistake on web pages is serving an image far larger than it will ever be displayed. A 4000-pixel photo shown in a 600-pixel column downloads roughly forty times more data than needed, and the browser then spends time scaling it down. On mobile connections this is the difference between a page that feels instant and one that does not.

The rule of thumb is to export at roughly twice the display size, which covers high-density screens without going overboard. A 600-pixel column wants an image around 1200 pixels wide. Beyond 2× the returns vanish, because no display resolves the extra detail.

Do not forget that dimensions and file size are separate constraints. Many upload forms cap file size rather than dimensions, which is where compression earns its keep: resize to the sensible display size first, then lower quality only as far as needed to get under the cap. Doing it the other way round — compressing a huge image hard — gives you a file that is both large and ugly.

Metadata: the invisible weight

Image files carry more than pixels. A photo straight off a phone or camera includes an EXIF block holding the camera model, exposure settings, the date and time, the lens, and very often the exact GPS coordinates where it was taken. Some files also carry an embedded colour profile and a full-size preview thumbnail.

This matters for two reasons. The first is size: metadata and embedded previews can add tens or even hundreds of kilobytes, which is a substantial share of a well-compressed web image. The second, and more important, is privacy. Posting an unprocessed photo taken at home can publish your address to anyone who opens the file properties.

Re-encoding through a canvas — which is what any browser-based resizer does — drops EXIF entirely as a side effect, because the canvas only ever receives decoded pixels. That is usually exactly what you want for anything going online. It is worth knowing, though, that it also discards the orientation flag and any colour profile, which is why a resized image very occasionally comes out rotated or slightly different in colour from the original. If you need the metadata kept, resize with a tool that explicitly preserves it.

Why upscaling disappoints

Enlarging an image cannot recover detail that was never captured. All a resizer can do is interpolate — guess intermediate pixels from their neighbours — which produces a larger but softer image. Doubling the dimensions of a small photo gives you four times the pixels and exactly the same amount of real information.

Modern AI upscalers do better by hallucinating plausible detail learned from training data, and for many purposes the result looks convincing. It is worth being clear about what that means though: the extra detail is invented, not recovered. For anything where accuracy matters — evidence, documents, product photography — that distinction is not academic.

The practical advice is simply to keep your originals. Storage is cheap, and an archived full-resolution master means you can always export a new size later. Working from an already-resized copy is how people end up with a folder of images that cannot be used for anything larger than a thumbnail.

There is one exception worth knowing. Modest upscaling — up to about 120% — is genuinely fine, because the interpolation has little work to do and the softening stays below what anyone notices. It is the 2× and 4× enlargements that fall apart. If you find yourself needing one regularly, that is a signal to change how you capture or export in the first place rather than a problem to solve at the end.

Sizes worth knowing

A great deal of resizing is done to hit a specific platform's expectations, and getting them wrong means your image is cropped somewhere unflattering. A few that come up constantly: an Instagram square post is 1080×1080 and a story is 1080×1920; a YouTube thumbnail is 1280×720; a LinkedIn banner is 1584×396; and an X post image displays best at 1600×900.

The one that catches people out is the banner. Very wide, short shapes such as LinkedIn and Facebook covers crop aggressively on mobile, usually from the sides, so anything important — a face, a logo, text — needs to sit near the centre. Designing a banner edge to edge and then discovering that half of it is invisible on a phone is an extremely common and avoidable mistake.

The other frequent case is document photos: passport and ID pictures are usually specified as a square at a fixed pixel size with a file-size cap, which is exactly the situation where you resize first and then lower quality until it fits. Guessing at quality without resizing rarely gets under the cap without looking bad.

A workflow that works

Put it together and the order matters more than any individual setting. Start from the original. Every re-encode of an already-compressed file costs quality that cannot come back.

Resize first, to about twice the display size. This does the heavy lifting on file size and costs nothing visible.

Then choose the format for the content — WebP or JPG for photographs, PNG for anything with transparency or text.

Then compress, starting at 80 and only going lower if a file-size cap forces you. Check the result at full size before accepting it, since artefacts that are invisible in a small preview can be obvious at scale.

The image resizer and compressor follows this order and shows the before-and-after sizes so you can see exactly what each step bought you. Everything happens in your browser, so nothing is uploaded. If you need to change format specifically, the image converter handles that, and the background remover is the tool to reach for when you need transparency in the first place.