Most advice about web resolution images starts with “export at 72 DPI.” That advice belongs to print workflows, not modern storefronts. A browser doesn't inspect the DPI value in a JPEG and decide how large to display it. It uses the image's pixel dimensions, the CSS layout, and responsive hints such as srcset and sizes.

For a Shopify merchant, the practical question isn't “Is this image 72 DPI?” It's “How many pixels will this slot need, which file should this device download, and can the page display it without slowing the experience?” That change in perspective affects product photography, collection tiles, hero banners, logos, social previews, and every image that contributes to Core Web Vitals.

Table of Contents

Why the 72 DPI Rule No Longer Runs the Web

DPI means dots per inch, a measurement used to describe how densely ink or toner is placed on a physical surface. A browser doesn't lay your image onto paper. It places raster pixels into a CSS layout, so changing an image from 72 DPI to 300 DPI in Photoshop won't add detail, change its HTML display size, or make it sharper on a phone.

The myth survived because designers often moved files between print software, desktop publishing tools, and web editors. Older screen workflows also encouraged a convenient 72 DPI convention. But the setting was never the controlling factor in an HTML document. A 1200 by 800 pixel image remains 1200 by 800 pixels regardless of the metadata value attached to it.

An infographic explaining that image resolution (DPI) does not affect how photos are displayed on web browsers.

The three variables that matter

Modern image sizing has three moving parts:

  • Source pixels: The intrinsic width and height stored in the file.
  • Rendered CSS size: The width and height the theme assigns to the image on the page.
  • Responsive delivery: The rules that help the browser select a suitable candidate for the visitor's viewport and device pixel ratio.

A file can be perfectly sharp but unnecessarily heavy if its source dimensions greatly exceed the rendered slot. It can also be lightweight but visibly soft when its pixel width is smaller than the slot requires on a high-density display. The right answer sits between those two failures.

The web platform gradually replaced developer-side image hacks with native browser selection. The W3C responsive image history records a Working Draft published on 26 February 2013, a W3C Note published on 7 November 2013, and responsive images described as a W3C recommendation by November 2016. The standard defines responsive images as assets that can adapt by changing their dimensions, crop, or source.

Practical rule: Stop exporting for a DPI number. Export for the largest CSS slot your design actually creates, then provide smaller candidates for narrower layouts.

If you want a hands-on refresher, this guide to compress and serve responsive images is useful because it treats compression and delivery as connected decisions rather than separate chores.

Pixels, DPI, and Device Pixel Ratio in Plain Language

A pixel is one colored unit in a raster image. A file that measures 800 by 800 contains a square grid of image data. DPI describes how densely physical dots are placed when that file is printed, so it doesn't determine how an HTML image occupies a browser viewport.

Screens add another term that causes confusion: device pixel ratio, or DPR. DPR describes the relationship between CSS pixels, which websites use for layout, and the physical pixels available on the display. A device with DPR 2 can use two physical pixels for each CSS pixel in a dimension, giving it more display detail without requiring the website to make every layout element twice as large.

Think of a kitchen wall covered with tiles. The CSS layout tells you the area to cover. DPR tells you how finely the wall is subdivided. If the visible image slot is 400 CSS pixels wide and the screen needs a 2x source for crisp detail, a candidate close to 800 intrinsic pixels wide is a sensible match. That doesn't mean every image should always be doubled. It means the browser needs candidates that correspond to the slot and the display density.

Device class Example DPR Source-width starting point for a full-width hero
Standard-density desktop 1x Match the hero's rendered CSS width
High-density phone 2x About twice the rendered CSS width
Very high-density fixed asset 3x About three times the rendered CSS width

These are selection anchors, not universal export laws. A fluid hero may render at very different widths across breakpoints, while a small icon may always occupy a fixed CSS size. Screen usage is fragmented rather than centered on one canonical dimension. Statcounter's worldwide screen-resolution data lists 1920x1080 as the most common desktop resolution in its July 2026 worldwide snapshot at 10.13%, while mobile usage includes prominent sizes such as 414x896, 360x800, 384x832, and 390x844.

That variety is why a single oversized “retina-ready” file isn't a complete strategy. You need enough source pixels for sharpness, but you also need the browser to avoid downloading desktop-sized imagery for a narrow mobile slot.

Responsive Delivery with srcset, sizes, and Density

The browser-native toolkit has three parts. srcset supplies candidates, sizes describes the image's expected CSS width, and density descriptors handle fixed-size assets where the layout width doesn't change.

A hand-drawn illustration demonstrating how srcset and sizes attributes in HTML provide responsive web images to browsers.

Use width descriptors for fluid Shopify imagery

A product card can occupy one width in a desktop grid and another on mobile. Width descriptors communicate the intrinsic width of each candidate:

<img
  src="shoe-800.webp"
  srcset="
    shoe-400.webp 400w,
    shoe-800.webp 800w,
    shoe-1200.webp 1200w
  "
  sizes="(max-width: 749px) 50vw, 25vw"
  width="800"
  height="800"
  alt="White leather running shoe">

The browser combines the candidate widths with the sizes hint and its knowledge of the current viewport and DPR. The width and height attributes reserve the aspect-ratio space before the file arrives, which helps prevent layout movement.

For a full-width banner, the sizes value should reflect the actual layout rather than a guess:

<img
  src="banner-1200.webp"
  srcset="
    banner-800.webp 800w,
    banner-1200.webp 1200w,
    banner-1920.webp 1920w,
    banner-2400.webp 2400w
  "
  sizes="100vw"
  width="2400"
  height="1200"
  alt="Spring collection displayed outdoors">

Width-based candidates are usually the right fit for product photos, collection cards, blog imagery, and hero sections because those assets are fluid. Density descriptors such as 1x, 2x, and 3x work better for fixed-size logos, icons, and interface graphics. A missing density descriptor defaults to 1x, so a high-DPI display may receive a bitmap that needs to be enlarged and looks soft. The responsive image guidance on srcset density and width descriptors explains why the choice depends on whether the rendered size is fixed or fluid.

Keep performance in the selection logic

A smaller candidate can reduce transfer time and help the browser paint the largest visible content sooner. MDN gives a concrete illustration, an 800px image at 128KB compared with a 480px version at 63KB, a saving of 65KB for that asset. The MDN responsive image guide uses this example to show why the smallest suitable candidate is preferable.

The browser still needs a fallback. Keep a normal src value, make sure it points to a valid image, and use meaningful alt text. Browsers that don't apply srcset can then render the fallback instead of showing a broken product card.

This short walkthrough also helps teams connect the markup to the browser's selection process:

Recommended Image Sizes by Shopify Asset Type

Shopify merchants shouldn't force every image into one universal export size. A product image serves zoom and merchandising, a collection tile needs consistent cropping, and a homepage hero must survive a wide viewport without sending its largest file to every visitor.

The following targets are practical catalog policies. They describe the source asset to prepare, not necessarily the file every visitor should download. Your theme should still generate or select responsive variants.

Product and merchandising imagery

A main product image at 2048 by 2048 pixels gives a square catalog asset with room for zoom and merchandising use. Keep the subject centered if the theme crops thumbnails, and use a consistent square canvas across variants so switching colors doesn't make the product jump.

Lifestyle product shots can use 1600 by 1000 pixels when the design calls for an 8:5 frame. Collection tiles work well at 800 by 800 pixels, provided the same aspect ratio and focal-point logic apply to every item in the grid.

For photographic assets, choose WebP as the general baseline and add AVIF where your delivery setup supports it. Keep a JPEG fallback for themes or workflows that still need broad compatibility. PNG is better reserved for graphics requiring transparency, since photographic PNG files can become unnecessarily large.

Theme, editorial, and brand assets

A full-bleed homepage hero can start at 2400 by 1200 pixels when the section uses a wide 2:1 composition. Keep important text and product details away from crop-prone edges, because responsive themes may use different object-fit behavior at mobile breakpoints.

Blog post hero imagery can use 1600 by 900 pixels for a 16:9 frame. That ratio also gives social systems a predictable horizontal composition, but social metadata should be generated separately when the preview requires a different crop.

A vector logo should remain an SVG where the brand system permits it. If a raster logo is necessary, keep the working file under 300 by 100 pixels for a rectangular lockup, while a square favicon can use 600 by 600 pixels as its source canvas. Use PNG for transparency when SVG isn't appropriate.

Shopify asset Source target Preferred format Main control
Main product image 2048x2048 WebP, AVIF where supported, JPEG fallback Square crop and zoom detail
Lifestyle product shot 1600x1000 WebP, AVIF where supported 8:5 composition
Collection thumbnail 800x800 WebP Consistent square grid
Homepage hero 2400x1200 WebP, AVIF where supported 2:1 crop-safe composition
Blog hero 1600x900 WebP, AVIF where supported 16:9 editorial frame
Rectangular logo Under 300x100 SVG, otherwise PNG Transparent brand lockup
Favicon source 600x600 SVG or PNG Square icon clarity

Don't treat these targets as permission to upload the largest file everywhere. Use the theme's responsive transformations, inspect the actual downloaded candidate, and compress each export until quality and byte weight reach a sensible balance. For a Shopify-specific implementation path, see this guide to resizing images in Shopify.

SEO, Social Previews, and Core Web Vitals Impact

Image sizing affects several destinations, and each destination has a different requirement. A product page image needs to communicate detail and survive cropping. A social card needs a dependable preview frame. A Discover image needs enough width to qualify for the presentation Google uses.

For social sharing, 1200x630 is a common Open Graph canvas. It gives Facebook, LinkedIn, X, Slack, and messaging applications a horizontal asset with predictable proportions. Square feeds have different creative needs, so teams often prepare 1080x1080 versions for Instagram and Pinterest rather than recycling a tightly cropped product detail image. These are channel assets, not substitutes for the responsive files embedded in the storefront.

Google Discover also has a separate threshold. The image SEO guidance from Blacksmith SEO states that Discover needs images at least 1200 pixels wide and the max-image-preview:large directive. That doesn't guarantee inclusion, but an undersized image can remove the asset from consideration for that presentation.

Performance depends on bytes and layout reservation

Pixel dimensions and file size aren't interchangeable. Doubling an image's width and height creates four times as many pixels, which usually raises byte weight sharply unless compression offsets it. A large original can delay the largest visible element, while an image without reserved dimensions can make nearby content shift as the browser discovers its height.

Use width and height attributes or an equivalent CSS aspect-ratio rule. Load the above-the-fold hero eagerly when it is the LCP candidate, and lazy-load below-the-fold product cards and editorial images. decoding="async" can allow the browser to decode noncritical imagery without blocking other work, but it doesn't fix an oversized source or poor candidate selection.

Don't assign an arbitrary compression budget to every asset. Set a stricter limit for small interface graphics, a measured target for product cards, and a higher allowance only when a large hero needs more visual information. The Shopify picture file-size guidance is useful for turning that decision into an asset policy rather than a one-off export habit.

SEO doesn't reward a blurry image because it loads quickly. It also doesn't reward a massive original that slows the page. The correct trade-off is a visually acceptable candidate matched to the rendered slot, with metadata, dimensions, and loading behavior that support the page around it.

Auditing a Catalog with Verified Fixes in RankEngine

A size table only helps if someone applies it consistently. In a real Shopify catalog, product media arrives from photographers, suppliers, agencies, and internal teams. Those sources rarely use the same crop, format, naming convention, or compression setting.

An audit-first workflow turns the recommendations into rules. Scan product, collection, blog, and homepage imagery, then flag each asset against the relevant policy:

  • Dimensions: Identify files that are too small for their intended slot or much larger than necessary.
  • Aspect ratio: Detect product and collection images that break the established visual frame.
  • Format: Separate photographic files from transparent graphics and vector brand assets.
  • File weight: Find candidates that can slow image delivery without improving the displayed result.
  • Metadata: Check filenames and alt text so the image remains understandable to shoppers and search systems.

A verified fix should propose the exact resized variant, format conversion, or renamed file instead of replacing creative work. A side-by-side preview lets a merchant confirm that the crop keeps the product, model, or focal subject intact before applying changes in bulk.

A hand-drawn sketch of a Catalog Fix Dashboard interface displaying product data, metrics, and list of fixes.

The maintainability benefit matters more than a single cleanup. Re-run the audit after a theme change, score new product uploads against the same policy, and keep an action history so the team can see which assets changed and why. That makes the size table a living merchandising standard rather than a forgotten document.

RankEngine audits Shopify content and image data, proposes supported fixes, writes supported changes through Shopify's Admin API, and verifies the live result before marking a fix complete. For teams also producing campaign banners, these scalable banner design insights can help keep creative variants aligned with the same responsive layout rules.

Pre-Publish Checklist and Common Questions

Before publishing a new image, check:

  • Dimensions: Match the asset to its Shopify slot and aspect ratio.
  • Format: Use WebP for photography, AVIF where supported, JPEG fallback where needed, PNG for transparency, and SVG for vector logos.
  • Compression: Compare visual quality at the actual rendered size, not only at full zoom.
  • Accessibility: Write concise alt text that describes the useful image content.
  • Loading: Eager-load the visible hero, lazy-load content below the fold, and reserve layout space with dimensions.

For broader store checks, use this Shopify SEO checklist.

What's the safest hero export? Start with the 2400x1200 homepage target when the design is a full-bleed 2:1 section. Let responsive delivery prevent smaller screens from receiving the largest candidate.

Does WebP replace JPEG? Use WebP as the baseline for photographic assets, but keep JPEG fallback support where your theme or downstream workflow requires it. AVIF can be added where supported.

What about images beyond Shopify's 4472px limit? Create a properly cropped working master, then export the largest practical catalog target instead of uploading an oversized original. If the source lacks enough detail, ClipNova recommends these upscalers, but inspect the result for artificial texture before publishing.

Why is a retina image still blurry? Check the rendered CSS width, the actual downloaded candidate, the sizes value, and whether a 2x or 3x option exists for fixed-size artwork.

RankEngine audits Shopify images across products, collections, blogs, and theme content, then records supported fixes and verifies them against the live store. Visit RankEngine to turn these web resolution image rules into a monitored catalog policy instead of a manual spreadsheet.