A Practical Guide to Image File Sizes and Formats for the Web

Every image competes for network, decode, memory, and rendering resources. A useful budget is page-specific: it accounts for the image’s role, audience, cache, viewport, and quality requirement. The ranges below are starting points to test, not universal pass/fail limits.

Starting Budgets by Use Case

These ranges illustrate a restrained web delivery budget. Your JPEG, WebP, or AVIF results may fall above or below them; adjust based on the source, encoder, rendered size, field performance, and visual review.

How to Turn Starting Ranges into Your Budget

The HTTP Archive page-weight report provides current distribution data, but a global median is not your audience. Google’s published “good” LCP threshold is 2.5 seconds at the 75th percentile of visits. Use your field data and a waterfall to divide the available time among server response, resource discovery, transfer, decoding, and render delay.

Start from a page-level transfer budget and allocate more to the images that carry the most user value. Revisit the table ranges when your layout, image count, audience, or quality requirement changes.

Format Is One Major Variable

The same source can produce very different sizes depending on the encoder and quality target. This table shows behavior to compare, not benchmark output for a universal 1200-pixel photo:

WebP or AVIF can beat a JPEG output in some comparisons, but no fixed percentage applies across sources and encoders. Both modern formats support transparency. For the tradeoffs, see our WebP vs AVIF guide.

You can create candidates with JPG to WebP, Convert to AVIF for its listed input formats, or Batch Convert for the formats shown by that tool.

Pixel Dimensions: The Hidden Multiplier

Pixel count, image content, bit depth, metadata, format, encoder, and settings all affect file size. Reducing unnecessary dimensions often gives the encoder much less data to represent.

A 4000 x 3000 image has 12 million pixels; 1200 x 900 has 1.08 million, 91% fewer pixels. At the same channel count and precision, that greatly reduces the uncompressed raster data presented to the encoder, although the final byte saving still depends on content and settings.

Responsive rule of thumb: offer candidates near the possible rendered widths and densities. If a content slot is 720 CSS pixels wide, a 1440-pixel candidate may suit a 2× display, but zoom, crop, layout changes, and higher densities can alter the choice. Let srcset and sizes describe the options.

Use Vizua's resize tool to create a candidate at the dimensions your layout needs. Then test the JPEG or PNG compressor as appropriate; a previously optimized source may not become smaller.

Compression Quality: Finding the Sweet Spot

Once your image is the right size and the right format, compression quality is the final dial. Here's a practical scenario showing how these three levers work together:

Illustrative workflow: start with a 4000 × 3000 master and keep it outside the delivery set.

1. Resize to a candidate such as 1200 × 900 when that matches the slot and target density
2. Export a WebP candidate at a chosen starting quality and inspect the real file
3. Export an AVIF candidate when your stack supports it, then compare size, appearance, and encoding cost

Choose the smallest candidate that meets the use case. The final saving and visible difference come from your actual source and outputs, not the example dimensions alone.

For detailed quality recommendations per format, see our guide: How to compress images without losing quality.

Special Cases

E-commerce product pages

Product photos need to remain useful at the storefront’s supported zoom. Generate responsive candidates from a protected master, test fine detail, and set separate budgets for the grid, main view, and zoom view. Marketplace upload requirements may be different from what the storefront should deliver.

Photography portfolios

Portfolios can serve responsive previews while offering an intentional high-resolution view when appropriate. Set dimensions and byte budgets from the layout and expected screens, then review texture, gradients, and color profiles.

Social sharing (Open Graph)

Open Graph image recommendations and accepted formats vary by platform and can change. A 1200 × 630 JPEG or PNG is a common cross-platform starting point, but verify the current destination guidance and preview. Crawlers fetch these files independently of your page’s lazy-loading behavior.

Total Page Image Budget

Build a page budget from your performance target. One possible initial allocation to test is:

• 1 hero image: ~150 KB
• 3-4 content images: ~100 KB each, totaling ~300-400 KB
• Thumbnails, avatars, icons: ~50 KB combined

This example is not a speed guarantee. Galleries and product grids can defer suitable offscreen images, but lazy-loaded resources still consume data when requested and can affect scrolling. Measure initial and interaction performance on representative devices and networks.

Frequently Asked Questions