Resizing Images for the Web: A Practical Guide

Compression gets all the attention, but resizing your images to the right dimensions before compressing them is just as important — and often more so. A 4000×3000 photo compressed to 80% is still paying the cost of encoding 12 million pixels when your page only ever displays 800,000 of them.

Why dimensions matter: the math

File size scales roughly with pixel count, which is width multiplied by height. Halve the width of an image (and maintain aspect ratio, so height also halves) and you have a quarter of the pixels to encode. That means a quarter of the raw data before compression even starts.

A real-world example: a typical iPhone photo at 4032×3024 has about 12.2 megapixels. Scaled to 1920×1440 (same ratio), that's 2.76 megapixels — about 77% fewer pixels. Even at the same quality setting, the 1920px version will be roughly 4× smaller. Add good compression on top and the savings compound further.

Compression is efficient at removing redundancy, but it can't remove pixels you didn't need in the first place. Every pixel you send that the browser won't display is wasted bandwidth.

Choosing the right width for your context

The right max width depends entirely on how the image will be displayed. A few common cases:

• Full-width hero images: 1920px is the standard. Most desktop monitors top out around 1920px wide; very few exceed 2560px. If you're targeting premium large screens too, 2560px is reasonable, but the file size jumps.
• Content column images (blog posts, articles): 800–1200px, depending on your layout's max-width. If your article column is 700px wide in CSS, a 700px image is all you need — sending a 1920px image wastes bandwidth and adds zero visual benefit.
• Product images in a grid: depends on how large they render. A three-column grid on desktop is often showing images at 300–400px. Sending 2000px originals means users download 25× more pixels than they see.
• Thumbnails: 300–640px, depending on use. Social sharing thumbnails are often 1200×630, which is actually quite large — that's a deliberate choice to support retina previews in link unfurls.
• Icons and avatars: 64–256px. These should be small and sharp, often PNG or WebP.

Retina and HiDPI screens

Retina screens (Apple's marketing term for 2× pixel-density displays) show images at double the CSS pixel count. An image displayed at 800px CSS width on a retina screen uses 1600 physical pixels. If you only send an 800px image, it'll look slightly soft on retina but sharp on standard screens.

The common approaches:

• Serve 2× images, but compress harder. A 1600px image at 60–65% quality looks sharp on retina and costs less bandwidth than an 800px image at 85%. Users can't see individual pixels at 2× density, so you can afford to compress more aggressively. This is the simplest approach and works well in practice.
• Use srcset in HTML to serve different sizes to different screens. This requires server-side work or a CDN but is the technically correct approach for performance-sensitive sites.
• Ignore it for most images. For body images in articles, slight softness on retina is usually acceptable. For hero images, product shots, or brand assets where sharpness matters, the 2× approach is worth the effort.

In the tool, the max-width field sets a single output size. For retina, set the max width to 2× your intended CSS display width (e.g., 1600px for an image displayed at 800px CSS), then compress at 65–70% instead of the usual 80%.

Resize first, then compress — order matters

It seems obvious, but it's worth being explicit: resize to your target dimensions before applying compression, not after. The encoder works on the pixels it's given. If you compress first and resize later, you're:

1. Encoding all the pixels you don't need (wasteful)
2. Then scaling down a lossy output, which can amplify artefacts from the compression

The tool handles this correctly: when you set a max width, it scales the image down before encoding, so the compression step only works on the pixels that will actually be in the output.

The compounding effect

Resize and compress together and the savings multiply. Here's a concrete example with a typical smartphone photo:

• Original: 4032×3024, JPEG (3.2 MB)
• Compressed only (80% JPEG, original dimensions): ~1.4 MB — 56% smaller
• Resized only to 1920×1440, no re-compression: ~1.1 MB — 66% smaller
• Resized to 1920×1440 and compressed at 80% JPEG: ~350 KB — 89% smaller
• Resized to 1920×1440 and exported as WebP at 80%: ~230 KB — 93% smaller

Same image. The final version is 14× smaller than the original with no visible quality difference at normal viewing sizes. That's the compounding effect of getting both dimensions and compression right.

Never upscale

Only resize images down. If you set a max width larger than the source image, leave it at the original size — or better, leave the field blank. Upscaling (making an image larger than its source) doesn't recover detail; it interpolates and blurs, and produces a larger file with no quality benefit. The tool only downscales: if the source is smaller than the max width you set, it passes through unchanged.

For more on the interplay between format, compression, and file size, see JPG vs PNG vs WebP and how to compress without losing quality. For the impact on page performance, see image formats and page speed.