Best Image Size for Websites: A Practical Guide

STILL IMAGE GUIDES

In this guide

Learn how to size website images for their display area, choose responsive formats, and reduce page weight without sacrificing useful detail.

Size for the rendered layout

There is no single best pixel size for every website image. Begin with the component that displays it: a card, article column, full-width hero or product gallery. Export enough pixels for the largest expected display and high-density screens, but avoid sending a giant original into a small thumbnail. If a design changes responsively, use multiple image sizes or the browser’s responsive image features rather than forcing one file to serve every layout.

Choose a format that fits

Photographs often work well as JPG or WebP. Transparent illustrations may need PNG or WebP. SVG is appropriate for many vector icons, though it is not a replacement for raster photos. Modern browsers support WebP broadly, but websites serving a varied audience can keep a fallback or use an image service that selects an appropriate format. Always compare the actual encoded output on representative images.

Image size affects page weight

An image that is much larger than its rendered area can increase download time, especially on mobile connections. Page speed depends on many things, including server response, scripts, fonts and layout, so compressing one image does not guarantee a particular Core Web Vitals score. It is still a practical improvement: use sensible dimensions, avoid unnecessary bytes, and reserve the largest files for content that benefits from them.

Do not forget accessibility

Write alternative text that describes the information or function of an image. Decorative images can use empty alternative text when the surrounding content already communicates their meaning. Use descriptive filenames when they help your asset library, and keep image width and height attributes in the page so the browser can reserve layout space. These details support people and browsers; they are separate from compression quality.

A reliable publishing checklist

Export at the size the layout needs, inspect sharp edges and text, confirm transparency, and compare file bytes. Add lazy loading to below-the-fold images where appropriate, but do not lazy-load the main hero image if that delays the largest contentful paint. Keep a high-quality source outside the public page bundle so future crops can be made cleanly.

Think in rendered slots, not one universal size

A product card, an article illustration and a wide hero do not occupy the same space. Measure the largest rendered width for each type of slot at the layouts your site supports. A source should cover that width at the intended display density without carrying several times more pixels than the layout can use. Keep separate sizes for materially different slots instead of forcing one giant file into every component.

Serve a suitable source at each viewport

Responsive markup can let the browser choose among width variants using `srcset` and `sizes`. Prepare those variants from the same high-quality source so the small phone image and large desktop image have consistent framing. If a content system generates variants, check that its crop does not cut off the subject. A responsive image is only useful when the browser is offered a genuinely smaller source for the narrower layout.

Protect layout stability

Set width and height attributes or an aspect-ratio box before the image finishes loading. The browser can reserve the correct space and avoid pushing text down when bytes arrive. Use descriptive alternative text when the image conveys information, and empty alternative text for purely decorative artwork. These page decisions support usability independently of compression and help visitors understand the content when images are unavailable.

Prioritize what appears first

Compress the main above-the-fold image carefully, but avoid lazy-loading the likely largest content image. Below-the-fold editorial images can usually load later. Do not preload every image: competing requests can delay the asset that matters most. The right priority depends on how the page is structured and what appears in the initial viewport, so check a real page load on a slower connection after updating the assets.

Measure the whole page after publishing

A smaller image file does not by itself guarantee a fast page. Inspect transferred bytes, layout shifts, image decode cost and the number of variants requested on representative devices. Compare a fresh browser load and a repeat visit, since caching changes what a visitor downloads. If the page remains slow, fonts, scripts, hosting and third-party code may be the larger cost. Treat each export as one part of a measured page-level improvement.

Give content editors useful guardrails

Document preferred image ratios and largest display widths next to the upload workflow in your content system. Editors can then prepare assets before they are placed into a page, instead of discovering after publishing that a portrait has been cropped awkwardly. Include a recommendation for transparent artwork and a naming convention for variants. A short, clear specification reduces both oversized uploads and inconsistent crops across an editorial team.

Balance quality with real viewing distance

A hero image often needs more visual detail than a small list thumbnail, but the largest file is not always the best-looking choice. Compare a few encodes at the actual display scale and keep a reasonable quality where texture remains natural. People rarely inspect a web photograph at extreme zoom, yet faces, product labels and thin line art can be sensitive to artifacts. Review each class of image instead of applying one numeric quality to everything.

Use decorative graphics differently from photography

An SVG can be suitable for a simple icon or logo because it describes vector shapes, while photographs need raster formats such as JPG, WebP or AVIF. This tool focuses on raster image formats and does not convert SVG. Keep vector artwork as a vector when the destination supports it; rasterizing too early can make it look soft when displayed at a larger size. For photos and raster illustrations, choose the most appropriate source dimensions and format.

Recheck the asset after a content change

A crop that worked in a previous layout may no longer suit a new card ratio or mobile breakpoint. Review important images when the page design changes and confirm that each responsive candidate still shows the intended subject. If a CDN transforms images automatically, inspect the transformed output and its cache behavior. Keep a stable source so a future layout change does not require recovering detail from a tiny optimized derivative.