You upload a photo straight from your phone or camera, and suddenly your "simple" landing page takes six seconds to load. Nothing looks wrong in the editor — the image just sits there at full size, quietly weighing 4 or 5 MB, even though it's only displayed in a box 300 pixels wide. Most people assume compression alone fixes this. It doesn't. The image is still being downloaded at its original, enormous pixel dimensions; the browser is just squeezing it down visually with CSS.
Resizing is the step that actually solves this — and it's different from compressing. Once you understand the relationship between display size, pixel dimensions, and screen density, picking the right export size for any image on your site stops being guesswork.
Resize images to roughly 2x the pixel dimensions of the largest size they'll display at on screen — this keeps them sharp on retina displays without wasting bandwidth on invisible detail. A full-width hero typically needs 1920–2560px wide, a blog content image 800–1200px, and a thumbnail 300–600px. Resize first, then compress for the smallest possible file.
What does "resizing for the web" actually mean?
Resizing changes the actual pixel dimensions of an image file — not how big it looks on a page, but how much raw pixel data exists inside the file itself. A photo straight from a modern phone camera is often 3000–4000 pixels wide. If that image only ever displays in a 600px-wide content column, the browser still downloads every one of those extra pixels — they're just invisible, scaled down by CSS, and wasted.
- Display size — how wide the image appears on the page, set by your CSS or layout. This is what the visitor sees.
- Pixel dimensions — the actual width and height of the file in pixels. This is what the visitor's browser has to download, regardless of how small the image looks on screen.
- Pixel density (DPR) — how many physical screen pixels represent one CSS pixel. Standard screens use 1x; retina and most modern phones use 2x or 3x, meaning they need more source pixels to render sharp.
Resizing for the web means matching pixel dimensions to display size times pixel density — no more, no less. Anything beyond that is pure waste; anything below it shows up as visible softness or pixelation.
Why the right size matters
Oversized images are one of the most common — and most fixable — causes of a slow website:
- Page speed and Core Web Vitals. Largest Contentful Paint, a key Google ranking signal, is directly affected by how long your largest visible image takes to download. An oversized hero image can single-handedly push a page into "poor" territory.
- Mobile data and load time. A visitor on a mobile connection downloading a 4000px-wide image for a 400px-wide display area is paying — in load time and data — for ten times more pixels than they'll ever see.
- Layout shift. Images without defined dimensions or wildly inconsistent aspect ratios cause content to jump around as the page loads, hurting both user experience and Cumulative Layout Shift scores.
- Server and CDN costs. At scale, serving full-resolution originals for every image view multiplies bandwidth costs for zero visual benefit.
Step-by-step: how to resize images correctly
- Find the image's actual display width. Check your site's CSS or design file for how wide the image's container is in pixels — not how wide your screen is, but the specific box the image sits in.
- Multiply by your target pixel density. For crisp results on retina and high-DPI screens, multiply the display width by 2 (e.g. a 600px container needs a 1200px-wide source image). Going to 3x rarely adds visible benefit and just adds file weight.
- Resize the actual file, not just the CSS. Use an image editor or a resizing tool to physically change the pixel dimensions — don't rely on width/height attributes or CSS to "shrink" an oversized original, since the full file still gets downloaded either way.
- Preserve the aspect ratio. Resize proportionally (lock width and height together) to avoid stretching or squashing. If you need a different aspect ratio, crop first, then resize.
- Compress after resizing. Once the pixel dimensions are correct, run the image through compression (JPEG quality settings, or a lossless PNG optimizer) for the final size reduction. Resizing and compressing solve different problems — do both, in that order.
-
Use responsive images for varying screen sizes. Where possible, generate a few sizes of the same image (e.g. 400px, 800px, 1600px) and let the browser pick the right one with the
srcsetattribute, so mobile visitors aren't downloading desktop-sized files. - Check the result at real display size. View the resized image in its actual position on the page, not zoomed in, to confirm it looks sharp where it actually matters.
Common mistakes that cost you speed or quality
1. Uploading camera- or phone-original files directly
A photo straight off a modern phone is often 3000–4000px wide and several megabytes — far larger than any web display area needs. Uploading it as-is means every visitor downloads pixels they'll never see.
2. Relying on CSS or HTML attributes to "resize"
Setting width="300" on an <img> tag or shrinking an image
with CSS only changes how it looks — the browser still downloads the full original file
size first. The actual pixel dimensions of the file have to change for any bandwidth
savings to happen.
3. Enlarging a small image past its native resolution
Resizing up doesn't add real detail — there's no information to recover, so the software has to invent pixels through interpolation, producing visible softness or blur. If you need a bigger image, you need a higher-resolution source, not a bigger export.
4. Using one oversized image for every screen size
Serving the same large, retina-ready image to every visitor — including those on small mobile screens with slower connections — wastes data for the majority of users. Responsive image sets fix this by matching the file size to the actual viewing context.
Real-world examples
These are representative results from resizing the same source photo for different on-page use cases:
The pattern is consistent: the gap between an unresized original and a correctly sized export grows fast, because file size scales with total pixel count — and most images are displayed at a fraction of their original resolution.
Recommended sizes by use case
A quick reference for common image placements and the pixel widths that typically cover them, including retina density.
| Use case | Typical display width | Recommended export width |
|---|---|---|
| Full-width hero / banner | 960–1280px | 1920–2560px |
| Blog / article content image | 600–700px | 800–1200px |
| Product photo (e-commerce) | 400–600px | 800–1200px |
| Gallery thumbnail | 150–300px | 300–600px |
| Avatar / profile icon | 40–80px | 80–160px |
| Social share preview (OG image) | Fixed by platform | 1200×630px |
| Background pattern / texture | Varies, often repeated | Match tile size, not screen size |
Resize your images right now — free
The Rebrixe Image Resizer runs entirely in your browser. Set exact pixel dimensions or pick a preset for hero, content, or thumbnail sizes — your images are never uploaded to a server. No account, no file size limit, no watermarks.