Best image size for web pages in 2026

There is no single "best" image size — the right answer depends on where the image appears, the screen it's viewed on, and what your performance budget allows. Here are the working numbers.

"What size should my images be?" is one of the most common questions in web performance, and it has the most contextually-dependent answer. A hero image and an avatar are both images, but the optimal size for each differs by an order of magnitude.

This article gives you concrete numbers — pixel dimensions and file size targets — for the most common image roles on a typical web page. Use them as defaults; adjust when you have specific constraints.

The two numbers that matter

Image size has two components, both of which affect performance:

  • Pixel dimensions — width × height in pixels. Affects download size, browser decode time, and memory usage.
  • File size — bytes on disk. Affects download time directly, especially on mobile.

Both need to be optimized. A 4000×3000 image at 200 KB is still problematic because the browser has to decode 12 million pixels into memory, which is slow on mobile devices. Conversely, a 800×600 image at 2 MB is problematic because it takes too long to download.

Hero images (main banner at top of page)

  • Pixel dimensions: 1920×1080 for desktop, 1080×1080 for mobile (or use responsive images).
  • File size target: under 200 KB. Aspirational: under 100 KB.
  • Format: WebP, fallback to JPG.
  • Quality: 75-82.

Hero images are usually your Largest Contentful Paint element, which means their load time directly affects your Core Web Vitals score. They're the most important image on the page to optimize aggressively.

For best results, serve different sizes to different devices using the srcset attribute or <picture> element. A phone doesn't need a 1920×1080 hero.

Content images (inline with article text)

  • Pixel dimensions: 1200×800 typical, up to 1600px wide for wider layouts.
  • File size target: under 150 KB.
  • Format: WebP for photos, PNG/WebP-lossless for screenshots or diagrams.
  • Quality: 80-85.

Most blog posts and articles display images at around 700-900 pixels wide. Serving 1200-1600px gives you 2× resolution for retina displays. Larger than that is wasted.

Thumbnails (grid layouts, product lists)

  • Pixel dimensions: 400×400 to 600×600.
  • File size target: under 30 KB each.
  • Format: WebP.
  • Quality: 70-78.

Thumbnails appear in large quantities — 20+ on a product listing page. Each one being even 100 KB adds up fast. Aggressive compression is fine here because thumbnails are viewed at small sizes.

Avatars and icons

  • Pixel dimensions: 128×128 to 256×256.
  • File size target: under 10 KB.
  • Format: WebP for photos, SVG for vector icons.
  • Quality: 75-80.

For square avatars, 256×256 is plenty even on retina. For icons, prefer SVG when possible — it's both smaller and infinitely scalable.

Product photography (e-commerce)

  • Listing thumbnails: 400×400, under 25 KB.
  • Product detail page: 1200×1200 main, 800×800 alternates.
  • Zoom view: 2400×2400 if zoom is supported, loaded on-demand only.
  • Format: WebP for browsers that support it, JPG fallback.
  • Quality: 82-85 (people scrutinize product photos).

E-commerce is the one place where you should err on the side of higher quality. A blurry product photo costs sales. The 2400×2400 zoom version should be loaded lazily — only when the user actually zooms in.

Background images

  • Pixel dimensions: 1920×1080 desktop, 1080×1920 mobile (different orientations).
  • File size target: under 100 KB.
  • Format: WebP.
  • Quality: 65-72.

Background images can take aggressive compression because they're decorative. Visible artifacts are okay as long as they don't compete with the foreground content.

The 2× rule for retina

Almost every modern device has a high-DPI display. iPhones, modern Macs, most current Android phones, and most laptops display at 2× the logical pixel count. If your image is displayed at 800 logical pixels wide, the screen actually renders it at 1600 physical pixels.

Rule: source images should be 2× the logical display size, with rare exceptions for very large hero images where you can get away with 1.5× because the device is so far from the user.

Don't go bigger than 2×

Some sources recommend 3× source images. This is overkill in 2026. Display densities have stopped increasing meaningfully. The visual benefit of 3× over 2× is imperceptible to almost everyone. The cost is 2.25× the bytes. Stick with 2× as your ceiling.

Core Web Vitals targets

To hit Google's "Good" thresholds:

  • LCP (Largest Contentful Paint) under 2.5 seconds. Almost always your hero image. Aggressive optimization here is the highest-leverage performance work.
  • Total image bytes on initial load: under 1 MB. Sub-500 KB is achievable and worth aiming for.
  • Number of image requests: under 20 on initial load. Lazy-load anything below the fold.

Practical workflow

  1. Take a good source photo.
  2. Resize it to 2× the largest display size it will appear at.
  3. Convert to WebP at quality 82.
  4. Strip metadata.
  5. Check the file size against the target for that image role.
  6. If over budget, drop the quality by 5 and recheck. Repeat until you're at target.

This handles 95% of cases. For the remaining 5% — very detailed images, gradients that band easily, or content where quality must be perfect — adjust upward as needed.


Get your images to the right size with pictoolkit's resize tool and compressor. Batch process a whole folder in seconds, entirely in your browser.

Keep reading

Related articles