How to Resize Images for Web — Dimensions, Retina, and Layout

A content migration imported 2,400 full-resolution camera uploads into a blog CMS. Every article page downloaded 15–25 MB of images for a 700 px reading column. Compression plugins on the server helped slightly, but Lighthouse still flagged poor LCP — because the browser was decoding 4000-pixel-wide bitmaps to display them at 700 pixels. The fix was not "compress harder." It was resize to match reality.

Resizing sets the pixel grid to how the image actually appears on screen. Everything else — compression, format choice, lazy loading — works on a right-sized file.

Quick answer

Resize web images to match how they actually display — roughly 1.5–2× the CSS width for retina screens, not full camera resolution. A 4000 px photo in a 600 px blog column wastes decode time and bandwidth even after compression. Set width and height attributes to prevent layout shift.

What is resizing images for the web?

Resizing changes the pixel dimensions of a raster image — scaling the width and height to a target size. Unlike compression, which encodes the same pixels more efficiently, resizing removes or adds pixels. For web deployment, you almost always downscale: export fewer pixels than the camera or design file contains.

Why resizing beats only compressing

Uploading a 4000-pixel-wide photo into a 600-pixel-wide blog column forces browsers to decode far more pixels than displayed. That wastes memory, slows rendering, and still leaves a large file even after compression.

Resizing sets the pixel grid to match (or slightly exceed) how the image appears on screen. Compression then works on an appropriately sized bitmap. See image compression for web for the compress step after resize.

Know your display targets

Before resizing, list where the image appears:

| Placement | Typical export width | Notes | |-----------|---------------------|-------| | Inline blog image | 800–1200 px max | Match column max-width | | Card thumbnail | 400–600 px | Often square or 4:3 crop | | Open Graph / social | 1200×630 px | Common OG standard | | Hero banner | 1600–1920 px | Match layout max-width | | Favicon / small icon | 32–192 px | Consider SVG instead |

Check your site's CSS max-width and grid columns — devtools "computed" width on the <img> element is the ground truth. Our open graph image sizing guide covers social preview dimensions in detail.

Retina (2×) rule

Hi-DPI screens pack more physical pixels per CSS pixel. A common approach:

Export width = CSS display width × 1.5 to 2

Example: 600 px CSS column → export 900–1200 px wide image. Going beyond 2× rarely helps visible sharpness but increases file size linearly with pixel count.

For icons and logos, SVG avoids raster scaling entirely. For photos, raster resize plus compression is standard. Retina images 2x explained walks through when 2× is worth the bytes.

Resize vs. crop

Resize — Scales entire image; preserves full scene.

Crop — Cuts to aspect ratio (1:1 product, 16:9 hero). Crop first when art direction needs a frame; resize second to pixel targets.

A portrait photo cropped to 16:9 for a hero needs intentional focal placement — not just scale-to-fit. Use Crop Image with a preview grid aligned to design mockups. Product photos on white backgrounds often need consistent padding percentages across catalog thumbnails.

When to resize images for the web

• Before CMS upload on blogs, shops, and marketing sites
• When migrating content libraries from full-resolution imports
• Creating responsive srcset variants at 400w, 800w, and 1200w
• Preparing Open Graph and Twitter card images at 1200×630
• Reducing email newsletter inline image weight

When not to resize (or resize carefully)

• Print workflows — Web resize targets screen DPI; print needs 300 DPI at physical dimensions
• Archival masters — Keep full-resolution originals; resize only deployment copies
• Upscaling small sources — A 300 px logo scaled to 1200 px creates blur
• Images needing future crop flexibility — Don't resize so aggressively you can't re-crop for a new layout
• Medical or forensic imagery — Pixel-level detail may be legally required at full resolution

Step-by-step resize workflow

1. Open Resize Image on Vertex Solutions.
2. Upload the source image.
3. Set target width (height scales proportionally unless you need exact crop).
4. Download the resized file.
5. Run through Compress Image or WebP Converter for deployment.

Maintain aspect ratio unless the design explicitly needs a crop — then use Crop Image before resize.

Responsive images in HTML

One resized file isn't enough for every viewport. Use srcset with multiple widths:

<img
  src="photo-800.webp"
  srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Description"
  width="800"
  height="450"
/>

The width and height attributes reserve space and reduce cumulative layout shift (CLS). Generate variants by resizing the same master to each breakpoint: thumb (400), content (800), hero (1600). Name consistently: post-hero-1600.webp, post-hero-800.webp.

Real-world example: blog migration

A 120-post blog migration had average inline images at 3200×2400 px and 2.4 MB each. Targets: 800 px content width, 1.5× retina = 1200 px export.

1. Batch resize to 1200 px width — average dropped to 380 KB before compression.
2. Compress at quality 82 — average 72 KB.
3. Add srcset with 400w and 800w variants for mobile.

Category page image weight fell from 28 MB to 2.1 MB. CLS score improved because width and height matched display dimensions. LCP improved because mobile downloaded 400w files (~18 KB) instead of 3200w originals.

Professional tips

• Verify EXIF orientation after resize — some portrait photos need manual rotation
• Fingerprint filenames when dimensions change (hero-800-a1b2c3.webp) so CDNs don't serve stale sizes
• Script three breakpoints for content sites: thumb (400), content (800), hero (1600)
• After deploy, verify CLS in Lighthouse — oversized files don't cause CLS if dimensions are set, but they still hurt LCP
• Photos → JPEG or WebP after resize; UI shots with text → PNG or WebP lossless

Common mistakes

• Upsizing small images — Scaling up a 300 px logo to 1200 px creates blur; source art must be large enough.
• Ignoring EXIF orientation — Some tools auto-rotate; verify portrait photos after resize.
• Single giant src — Mobile downloads desktop heroes without srcset.
• Resizing after compression — Resize first, compress second. Reversing the order wastes effort.
• Forgetting display dimensions on img — Layout shift hurts CLS even with right-sized files.

See common mistakes when resizing images for more failure patterns.

Troubleshooting

| Problem | Likely cause | Fix | |---------|--------------|-----| | Image looks soft on retina | Export too small | Increase to 1.5–2× CSS width | | Layout jumps when image loads | Missing width/height | Set attributes to display dimensions | | Mobile downloads huge file | No srcset | Add 400w and 800w variants | | Portrait photo appears sideways | EXIF orientation | Re-export with rotation applied | | Hero subject cropped awkwardly | Scale-to-fit on wrong ratio | Crop to 16:9 before resize |

Privacy and browser processing

Resizing in the browser keeps files on your device. Vertex Solutions image tools process locally — nothing uploads to a server. For client galleries or unreleased campaign assets, browser-based resize avoids sending pixels to third-party servers. Details in GDPR and browser processing.

Limitations

• Cannot add real detail — Upscaling interpolates existing pixels; it does not recover sharpness.
• Raster only — SVG icons scale without resize; this workflow covers JPEG, PNG, and WebP.
• Aspect ratio changes need crop — Resize alone cannot turn 3:2 into 16:9 without distortion or letterboxing.
• Batch jobs need naming discipline — Without consistent filenames, CDN cache and CMS references break.
• Does not replace responsive markup — A single resized file still downloads on every viewport without srcset.

When resize alone isn't enough, crop for art direction, compress via Compress Image, convert format with PNG to JPG when transparency isn't needed, or use an image CDN for on-the-fly sizing at scale.

Related tools

• Resize Image — Core resizing
• Crop Image — Aspect ratio before scale
• Compress Image — Shrink resized outputs
• WebP Converter — Modern format after resize

Related articles

• Image Compression for the Web — Compress step after resize
• Common Mistakes When Resizing Images — Failure patterns to avoid
• Retina Images 2x Explained — When 2× is worth it
• Core Web Vitals and Images — LCP and CLS targets

Key takeaways

• Export width = CSS display width × 1.5 to 2 for retina; going beyond 2× rarely improves sharpness but increases file size.
• Inline blog images often need 800–1200 px max width; card thumbnails 400–600 px; Open Graph images 1200×630 px.
• Always set width and height on img tags and use srcset with multiple variants so mobile does not download desktop heroes.
• Crop before resize when art direction needs a specific aspect ratio — do not stretch a portrait photo to fit a 16:9 hero without cropping.

Conclusion

Resizing is the step most teams skip because compression feels easier. Match pixel dimensions to display size first — roughly 1.5–2× CSS width for retina — then compress and deploy with srcset and explicit width/height. A right-sized image loads faster, decodes faster, and keeps layout stable. Full camera resolution belongs in your archive, not in every visitor's browser.