Best DPI for Web Images: Resolution Guide for Websites

DPI Is Irrelevant for Web. Pixel Dimensions Are Everything.

Browsers don't care about DPI. They ignore the DPI (or PPI) metadata embedded in image files entirely and render only from pixel dimensions. A 1200x800 image saved at 72 DPI displays exactly the same as one saved at 300 DPI. Same pixels in, same output on screen.

Print workflows created the confusion. Designers who work across both mediums often assume the DPI setting they use for print should carry over to web exports. It doesn't. You can save at any DPI value and it won't change the rendering, the file size, or the visual quality in a browser. The number exists purely as metadata that browsers discard.

Why the '72 DPI for Web' Rule Won't Die

The 72 DPI convention dates back to early Mac displays in the 1980s, which happened to have screens running at 72 pixels per inch. At that resolution, one point in the operating system equaled one pixel on screen. Design software of the era used DPI to calculate display size, so setting an image to 72 DPI made it appear at 'true size' on those monitors.

Modern displays range from 96 PPI on budget monitors to 458 PPI on some phones. Browsers stopped using DPI for rendering calculations long ago. The '72 DPI' instruction stuck in style guides and tutorials long after it stopped meaning anything. Following it today wastes no bytes and changes nothing visually. Just ignore it.

What Actually Matters for Web Images

• Pixel dimensions: Serve images at the size they'll display (or 2x for retina). A hero image shown at 1200 CSS pixels wide should be 1200 px (standard) or 2400 px (retina).
• File format: Use WebP for broad compatibility with excellent compression. Use AVIF for even better compression where supported. Fall back to JPEG for photos and PNG for graphics with transparency.
• Compression: A well-compressed WebP image can be 25-35% smaller than an equivalent JPEG with no visible quality loss.
• Lazy loading: Add loading="lazy" to images below the fold to defer loading until they enter the viewport.

Responsive Images for HiDPI Screens

On retina (2x) and high-density (3x) screens, images need more pixels to appear sharp. Use the HTML srcset attribute to serve different resolutions:

The browser picks the right image based on viewport width and device pixel ratio, delivering sharp output without wasting bandwidth on standard displays.

<img
  src="hero-800w.webp"
  srcset="hero-800w.webp 800w,
          hero-1200w.webp 1200w,
          hero-2400w.webp 2400w"
  sizes="(max-width: 600px) 100vw, 1200px"
  alt="Hero image"
  loading="lazy"
/>

Web vs Print: Why DPI Rules Don't Transfer

Print and web use fundamentally different rendering models. Printers lay down physical ink dots at a fixed density, so DPI directly controls quality. Browsers render pixels to a screen, and the screen's own PPI determines sharpness, not the image's embedded DPI tag.

A 300 DPI JPEG you export for a magazine looks identical in a browser to the same file resaved at 72 DPI. No quality difference. No file size difference. The only real difference is the number sitting in an EXIF field that browsers skip. Save for web by pixel count alone and you'll get the same result every time.

Web Image Optimization Checklist

Calculate the exact pixel dimensions you need for any layout with our Image Size Calculator.

• Resize images to their maximum display size (don't serve a 4000 px image for a 1200 px container).
• Use WebP or AVIF format with quality setting of 75-85%.
• Provide 1x and 2x versions via srcset.
• Add width and height attributes to prevent layout shift.
• Use lazy loading for images below the initial viewport.
• Consider using a CDN with automatic format negotiation.

Common Web Image Sizes by Use Case

Web image sizing follows layout requirements, not DPI. The table below shows recommended pixel dimensions for typical web image placements. For retina screens, double the pixel width to avoid blurry output on high-density displays.

Exporting Images for Web in Design Software

The DPI field in your export dialog does nothing for web output. What controls quality and file size is the pixel dimensions and the output format.

In Photoshop: go to Image > Export > Export As and choose WebP or JPEG. Set quality to 75-85%. The resolution field only affects print output. You can leave it at any value for web.

In Figma: export at 1x for standard screens and 2x for retina. The DPI property does nothing. Only the multiplier changes the final pixel dimensions.

In Illustrator: use Export > Export for Screens. Set the unit to pixels and match the target container size from your CSS layout.

In Canva: download as WebP or JPEG. Canva sets resolution automatically. The download size slider controls compression, not DPI.

Is DPI Something You Should Ever Set for Web?

No. DPI is a print concept with no functional role in web image delivery. You don't need to set it, track it, or standardize it across your team. The only number that matters for web is pixel dimensions.

The one scenario where DPI metadata shows up in web workflows: some CMSs or image pipelines read the embedded DPI value to infer display size. If your tooling does this, set images to 96 DPI to match the CSS reference pixel standard. But most modern tools don't rely on this, and browsers never do.

Save at the right pixel dimensions, compress well, use a modern format, and implement srcset. That covers everything that actually affects web image quality. DPI is noise.