Imagyc›Articles

Image resolution for desktop and mobile without slowing your website

Published October 9, 2026 · 8 min read

The right image resolution depends on its display space and the sharpness required for that use. A thumbnail, a zoomable product photo and a full-width banner do not need the same file.

Always sending the largest version wastes data. Shrinking every image aggressively can remove product details and make lettering hard to read. A practical approach is to prepare sizes that match the layout and let the browser choose a suitable candidate.

For a typical website, that means maintaining a few defined versions, inspecting them on phones and reserving larger images for situations where they add useful information.

Dimensions file size and resolution are different measurements

“High resolution” can mean different things. On the web, a useful starting measurement is the pixel dimension, such as 800 × 600.

File size in KB or MB also depends on format, compression and content. Images with identical dimensions can have very different file sizes. A detailed photograph is generally harder to compress than a simple illustration.

PPI means pixels per inch and relates pixels to physical size, particularly for printing. Changing that value without resampling does not add pixels.¹ Changing “72” to “300” in an editor does not by itself make a website image sharper.

Do not confuse file pixels with CSS pixels used to arrange the page. This distinction explains why a phone may benefit from a source with more pixels than the width reported by its layout.

Start by measuring the display space

An image occupying 600 CSS pixels does not need to match an entire 1,920-pixel monitor. If it sits in a column, the column's width is the starting reference.

On phones, account for margins. A viewport 390 CSS pixels wide can display an image 358 pixels wide when there is a 16-pixel margin on each side.

The viewport is the space available to the page inside the browser. It can change with window size, device orientation and layout. “Desktop” and “mobile” help organize your work, but do not independently determine the file dimensions.

Measure the main components: thumbnails, cards, article images, primary product photos and banners. Use those measurements to prepare the versions.

How pixel density changes the calculation

Screen density can make one CSS pixel occupy more than one physical pixel. This relationship is called DPR, or device pixel ratio.²

An image displayed at 400 CSS pixels wide may benefit from an 800-pixel source on a DPR 2 screen.³ That describes a relationship between display size and density, not a requirement that every mobile photo be 800 pixels wide.

As a starting calculation, use: source width ≈ displayed width × target density.

A photo displayed at 360 CSS pixels can be tested with a 720-pixel source for 2x density. At 700 CSS pixels, the corresponding 2x starting point is 1,400 pixels.

Higher-DPR phones and high-density monitors exist. Sending the largest possible version to every visitor still may not be worthwhile. Compare 1x, 2x and larger versions when the visible benefit justifies them. Product textures and lettering need different scrutiny from a decorative photo.

Practical ranges to start with

These ranges are editorial starting points for common layouts, based on display space and testing at roughly up to 2x density. They are not Google requirements or universal dimensions. Numbers indicate width; height should follow the chosen aspect ratio.

These options create candidates; they do not require every visitor to download the largest one. A narrow desktop card may need fewer source pixels than a full-width image on a high-density phone.

Banners extending beyond these display areas need a fresh measurement. Do not enlarge every image's standard just because one placement is wider.

Why excessive pixels can delay a page

More pixels can require more encoded information and more display work. Compression affects the final file size, but a small download does not automatically eliminate the cost of decoding a large image.⁴

Consider the arithmetic. An 800 × 600 image contains 480,000 pixels. A 1,600 × 1,200 image contains 1.92 million. Doubling width and height quadruples the pixel count.

This does not mean the file becomes exactly four times larger or loading takes four times longer. It shows why increasing dimensions deserves a reason.

On a catalog page with dozens of products, unnecessary data adds up. If every thumbnail uses the original intended for zoom, visitors download detail they cannot use in that small space.

Making an image smaller with CSS does not shrink the download

A browser can display a photo at a small size while receiving a large file. Setting its visual width to 300 pixels does not automatically generate a lightweight 300-pixel version.

Create smaller files and configure their delivery. srcset lists available candidates; sizes describes the layout space when width descriptors are used.^{3, 5}

The browser uses this information and its display context to select a candidate. Selection can vary by implementation and circumstances; srcset should not be treated as a rigid download command.

Accurate configuration matters. If the website reports that an image occupies the whole screen when it actually sits in a narrow column, it can encourage selection of an unnecessarily large source.

A responsive image example

Consider an 8:5 image limited to 640 CSS pixels on desktop, with 16-pixel side margins on phones. It can have sources 320, 640, 960 and 1,280 pixels wide, sharing the same content and aspect ratio.

An example for the person maintaining the website is:⁵

<img
src="product-640.webp"
srcset="product-320.webp 320w,
product-640.webp 640w,
product-960.webp 960w,
product-1280.webp 1280w"
sizes="(max-width: 672px) calc(100vw - 32px), 640px"
width="1280" height="800"
alt="Blue handbag shown from the front">

The example assumes the CSS follows the stated layout. The source files must exist at the declared widths. sizes does not create or resize files.

For an image that dominates the opening screen, assess loading priority. Lazy loading may suit an image farther down. Position, as well as resolution, informs that choice.

Aspect ratio cropping and perceived quality

Aspect ratio relates width to height. A 1,200 × 800 source has a 3:2 ratio. If its placement is square, crop it or accept empty space; stretching can distort the product.

CSS object-fit: cover fills an area while preserving proportion and cropping part of the content.⁶ It does not independently reduce the downloaded file. Cropping during export can provide a source better suited to the placement.

For banners, assess a dedicated mobile crop. A horizontal composition can leave the face, product or text too small on a narrow screen. The picture element supports choosing different sources for this adaptation.⁷

Where possible, keep important wording as page text. Lettering inside a photo needs sufficient pixels to remain readable and can constrain the layout's flexibility.

When a larger source makes sense

A larger image can be needed for zoomed detail, a wide placement on a high-density screen or another destination with specific requirements.

For product zoom, keep the browsing version light and consider loading the enlargement source when the feature is used. The zoom should reveal real detail; enlarging a small image does not recreate missing texture.

Some presentation requirements are specific. For large Discover images, Google recommends at least 1,200 pixels in width, more than 300,000 total pixels, a suitable 16:9 composition and large previews enabled.⁸ This does not require every thumbnail on the website to be that wide.

Keep a source appropriate for that purpose and deliver smaller candidates where the layout permits. Making a large image available and making everyone download it are separate decisions.

Resolution works with compression and loading

After setting dimensions, compare formats and quality. A correctly sized source can still be heavy because of its export settings. An overly compressed version can look blurry despite having many pixels.

Choose the crop and dimensions first, adjust compression next and inspect at the intended display size. Keep the original so new candidates do not have to be generated from a degraded thumbnail.

Reserve page space through proportional width and height, preventing content movement during loading.⁹ The image responsible for LCP should not be lazy-loaded.¹⁰ These measures complement resolution control.

One KB target does not fit every image. An avatar and a zoomable technical photograph serve different purposes. Budget images across the whole page, especially in galleries and product listings.

How to verify the reduction preserved quality

Compare the same page before and after changes on phones and desktop. Inspect detail, lettering and colors at normal browsing size. Check zoom separately where it exists.

In the browser's network panel, check which source was requested and how many bytes arrived. Changing display size without changing the source can create an impression of optimization while the download remains the same.

Use PageSpeed Insights to assess loading and consult real-user data when available.¹¹ Look for changes in LCP and layout stability alongside transferred bytes. Faster loading does not compensate for a photo that prevents a customer from assessing the product.

If two candidates look equivalent but the smaller one transfers less data and performs well, it may be sufficient for that placement. If an important texture disappears, adjust quality or dimensions for that particular use.

Organize sources around the layout, preserve the original and review sizes when the design changes. This keeps the page responsive without forcing a choice between heavy images and missing detail.