How to Resize Images for Web

Resizing images for the web is the single highest-leverage performance tweak most sites never finish. A 4000 × 3000 phone photo served into a 600 px card wastes bandwidth, burns mobile data, and tanks your Largest Contentful Paint score. The fix is to ship pixels close to the size the browser actually paints, usually with a 2x buffer for retina displays. Getting this right means choosing real pixel dimensions, understanding device pixel ratio, and knowing when downscaling is enough versus when you need to crop. This guide walks through each decision and the trade-offs between quality and file size.

Start from the painted size, not the source

Open the page in a browser, inspect the image, and note its rendered CSS width in pixels. That number — not the source file’s intrinsic size — is the anchor for every resize decision. A hero image painted at 1200 px wide should not ship a 4800 px source, and a 96 px avatar has no business being a 1080p portrait.

Once you know the painted size, you pick a target. For non-retina, target equals painted size. For retina support, double it. For sites with 3x devices (high-end phones), triple it only for images where razor-sharp detail matters.

Pixel dimensions versus file size

Pixel dimensions (width and height) control sharpness. File size (KB) controls how fast the image downloads. They correlate but they are not the same knob. Halving the dimensions of a photo roughly quarters the file size because pixels are a 2D grid. Halving the quality slider (JPEG 90 → 45) also shrinks bytes but leaves dimensions untouched, trading clarity for speed.

Resize first, compress second. Resizing throws away data you didn’t need; compression throws away data you maybe did.

Device pixel ratio and the 2x rule

A CSS pixel and a device pixel are not the same. A modern phone with a device pixel ratio (DPR) of 2 or 3 paints multiple hardware pixels for every CSS pixel. If your image element is width: 400px in CSS and the user has DPR 2, the browser can show up to 800 hardware pixels of detail. Ship a 400 px source and it will look soft; ship 800 px and it looks crisp.

The pragmatic rule: always export at 2x painted size, and only bother with 3x for critical hero imagery where customers will zoom in.

Responsive sizing with srcset

Rather than choosing one size, the srcset attribute lets you offer a menu and let the browser pick. A typical product image might ship at 400 px, 800 px, and 1200 px widths.

<img
  src="/img/product-800.jpg"
  srcset="/img/product-400.jpg 400w,
          /img/product-800.jpg 800w,
          /img/product-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="Red leather wallet, front view"
/>

The sizes attribute tells the browser how big the image will render, so it can pick the right source before the CSS has even loaded.

Downscale versus crop

Downscaling preserves the whole frame at a smaller size; cropping throws away edges to reshape or tighten the composition. Use downscaling when the aspect ratio is already right and you just need fewer pixels. Use cropping when the subject is lost in dead space or when a layout demands a specific ratio — think square tiles, 16:9 hero banners, or 4:5 Instagram feed posts.

Mixing them is common: crop to the right ratio first, then downscale to the target width. Doing downscale first wastes CPU resizing pixels you’ll throw away.

Aspect ratio locks

Most resize tools default to “constrain proportions” — change one dimension and the other follows. Disable this only when you deliberately want to stretch (almost never) or when you’re padding a canvas to a fixed ratio. A face stretched by 8% from an accidental unlock is uncanny and obvious.

If you need a fixed output ratio from a mismatched source, the correct flow is: set the canvas, position the image inside it, fill the remaining space with a solid background or blurred extension.

Quality versus size trade-offs

JPEG quality settings are non-linear. The drop from 100 to 90 is imperceptible and saves 40–60% of the bytes. The drop from 90 to 75 saves another 30% with barely any visible cost on photos. Below 60 you start seeing blocking and color banding, especially on skies and gradients.

• Hero photography: JPEG 80–85 or WebP 80.
• Thumbnails and list tiles: JPEG 70–75 or WebP 70.
• UI screenshots and diagrams: PNG or WebP lossless.
• Logos and flat illustrations: SVG if you have the source, else PNG.

Format matters more than settings

The biggest quality-per-byte win is usually picking the right format. WebP is 25–35% smaller than JPEG at equivalent quality. AVIF is another 20–30% smaller than WebP but encodes slowly. For photographs on modern browsers, ship WebP with a JPEG fallback; for graphics with few colors, stay with PNG or switch to SVG.

Don’t convert PNG to JPEG for transparent logos — you’ll get a white box around them. Don’t convert JPEG to PNG to “upgrade quality” either; you can’t un-bake the JPEG artifacts and the PNG will be huge.

Common screen and export presets

Useful starting sizes to keep in your head:

• Blog hero: 1200 × 630 (also the Open Graph preview default).
• Product grid tile: 600 × 600 at 2x source.
• Avatar: 80–160 px painted, so 160–320 px source.
• Inline article image: 720 px painted, 1440 px source.
• Full-bleed hero on desktop: 1920 × 1080 or 2560 × 1440 for 4K support.

Batch resizing workflow

For product catalogs and article batches, set a maximum width and let the tool downscale anything larger while leaving smaller files alone. A typical rule is “no image wider than 1600 px, JPEG 82.” Run it over the whole folder and you’ll cut 60–80% of the bytes from an untouched photo library without touching the good, smaller assets.

Always keep the originals. Resized copies are derivative; if you lose them, you can always regenerate from the masters.

The picture element for art direction

When srcset isn’t enough because you want a fundamentally different crop at different breakpoints (wide hero on desktop, tight portrait on mobile), use the <picture> element:

<picture>
  <source media="(max-width: 600px)"
          srcset="/img/hero-portrait.jpg">
  <source media="(min-width: 601px)"
          srcset="/img/hero-landscape.jpg">
  <img src="/img/hero-landscape.jpg"
       alt="Team at the summit">
</picture>

The <picture> element lets you serve genuinely different images per breakpoint, not just the same image at different sizes.

Lazy loading the right way

The loading="lazy" attribute defers offscreen images until they’re about to scroll into view. This is almost always a good idea — except for the hero image above the fold, which should load eagerly to hit your LCP target.

<!-- Above the fold -->
<img src="/hero.jpg" fetchpriority="high" alt="...">

<!-- Below the fold -->
<img src="/below-fold.jpg" loading="lazy" alt="...">

The fetchpriority="high" hint on the LCP image is the newest tool; modern browsers use it to prioritize that download over other page assets.

Resampling algorithms and why they matter

When a tool shrinks an image, it has to compute what each output pixel should be from a region of source pixels. Different algorithms give different results:

• Nearest-neighbor: picks the closest source pixel. Fast, but produces jagged, pixelated output. Avoid except for pixel art.
• Bilinear: averages the four nearest pixels. Fast, decent for small downscales, slightly blurry on big ones.
• Bicubic: samples a 4 × 4 neighborhood with a smoother curve. The default in most editors; good balance of speed and quality.
• Lanczos: uses a sinc-based filter over an 8 × 8 window. The best-looking for significant downscales but slower and can ring slightly.

For web workflows, bicubic or Lanczos is the right default. Cheap tools sometimes default to bilinear or worse; if your downscales look soft or jagged, check which algorithm is in play.

Upscaling: the honest answer

You cannot add detail that isn’t there. Classical upscalers (bicubic, Lanczos) just stretch existing pixels into a bigger grid, producing a blurry result. AI upscalers (ESRGAN, Topaz, Nvidia’s tools) hallucinate plausible detail based on training data, which can look impressive but also invents specifics that weren’t in the source.

The rule: always start from the highest-resolution source you have. Never upscale a web JPEG for print. If you absolutely must, AI upscaling at 2× is acceptable for non-critical uses; 4× starts showing obvious hallucination artifacts.

CDN-side resizing

Rather than generating every size variant at build time, modern CDNs (Cloudflare Images, Imgix, Cloudinary, Vercel Image Optimization) resize on the fly from a single high-res source. You upload one master, the CDN serves the right size for each request.

The tradeoff: first request is slow because the CDN computes the variant, subsequent requests are cached. Costs scale with unique variants served. For content sites, this is often cheaper and simpler than maintaining a pre-generated size ladder.

Common mistakes

The mistake every site makes at least once: uploading a 20 MB camera RAW export straight into the CMS because “the browser will just shrink it.” The browser does shrink it, after downloading every byte over cellular. Other classics: unlocking aspect ratio and stretching faces, resizing a JPEG up (you can’t invent pixels, you only invent blur), and saving as PNG to “keep quality” for photographs — PNG is lossless but 4–8× larger than JPEG for photos. Also watch for tools that resample at low quality; a fast nearest-neighbor downscale produces jagged edges where bicubic or Lanczos would be smooth.

Run the numbers

Drop a file into our image resizer to set exact pixel dimensions, preview the output, and export in one click. For the compression step afterwards, the image compressor handles quality trade-offs without touching dimensions. And when you need to change the composition rather than just the size, the image cropper lets you lock a ratio and frame the subject.