How to Choose the Right Image Resolution for the Web

Image resolution is the most common performance lever on a website. Too low and images look bad on high-DPI screens. Too high and pages load slowly, especially on mobile. This guide covers the right resolution for every use case, the math, and the format trade-offs.

What "resolution" means

Image resolution is the number of pixels in the image, usually written as "width x height" (e.g. 1920 × 1080) or as the count of pixels on the long edge. A higher resolution means more pixels, more detail, and a larger file size.

For the web, the relevant question is not "how many pixels" but "how many pixels relative to how the image will be displayed". A 400-pixel-wide image looks fine when displayed at 400 CSS pixels. The same image looks blurry when displayed at 800 CSS pixels (the browser stretches it). The same image looks wasteful when displayed at 200 CSS pixels (the file is twice as big as it needs to be).

The right resolution: the maximum size the image will be displayed at, multiplied by the device pixel ratio (DPR) of the target devices.

What DPR is and why it matters

Device pixel ratio (DPR) is the ratio of physical pixels to CSS pixels. A 1x DPR display has 1 physical pixel per CSS pixel (older monitors, low-end phones). A 2x DPR display has 2 physical pixels per CSS pixel (most modern phones, Retina MacBooks). A 3x DPR display has 3 (some high-end Android phones).

For a sharp image on a 2x display, the image needs to be 2x the CSS size. An image displayed at 200 CSS pixels on a 2x display needs to be 400 physical pixels wide. If the image is only 200 physical pixels, the browser stretches it and it looks blurry.

The math:

• CSS size × DPR = required physical pixels
• 200 CSS × 2 DPR = 400 physical pixels minimum
• For a 200x200 thumbnail, the file should be at least 400x400.

Practical resolution targets

For most websites, the right resolution depends on where the image is used:

Hero images (full-width above the fold)

Hero images span the full width of the page, typically 1200-1920 CSS pixels. For 2x DPR, that is 2400-3840 physical pixels on the long edge. The practical upper bound: most monitors are 2560 × 1440, so anything larger is wasted. The right target: 1920-2560 pixels on the long edge, at 2x DPR.

Content images (blog posts, articles)

Content images are usually displayed at 600-1000 CSS pixels (within a text column). For 2x DPR, that is 1200-2000 physical pixels. The right target: 1200-1600 pixels on the long edge, at 2x DPR. Anything larger is wasted for the typical reader.

Thumbnails (cards, lists, grids)

Thumbnails are usually 200-400 CSS pixels. For 2x DPR, that is 400-800 physical pixels. The right target: 400-600 pixels on the long edge. Larger is wasted; smaller looks blurry on high-DPI.

Profile photos / avatars

Avatars are usually 80-200 CSS pixels. For 2x DPR, that is 160-400 physical pixels. The right target: 200-400 pixels. Larger is wasted for the typical use case.

Icons and logos

Icons and logos are usually displayed at 16-64 CSS pixels. The right target: SVG (vector) for icons and logos, or PNG at 2x DPR (32-128 physical pixels) for raster fallbacks.

The 2x rule

The simplest rule: serve images at 2x the CSS size, on the long edge. This covers 95% of devices. A few caveats:

• High-DPI displays (3x) — some Android phones and high-end displays are 3x. For 3x, you would serve 3x the CSS size. But 2x already looks good on 3x; the difference between 2x and 3x is usually imperceptible. Most sites stop at 2x.
• Low-end devices (1x) — older devices, low-end phones, and cheap laptops may be 1x. They render 2x images downsampled, which is fine — the file is a bit larger than needed, but the rendering is correct. Serving 1x for low-end and 2x for high-end is the "responsive images" approach, but it is often more trouble than it is worth.

For 95% of sites, the 2x rule is the right starting point. Optimize further only if you have evidence (Lighthouse audits, real-user metrics) that the 2x file size is a bottleneck.

Responsive images with srcset

For high-traffic sites, the right approach is to serve different sizes to different devices. The HTML:

<img
  src="image-1200.jpg"
  srcset="image-800.jpg 800w,
          image-1200.jpg 1200w,
          image-2000.jpg 2000w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         800px"
  alt="...">

This tells the browser: "I have three sizes (800, 1200, 2000 pixels). On small screens, use 100% of the viewport width. On medium screens, 50%. On large, 800 pixels. Pick the closest size."

The browser uses this hint to download only the size it needs. A phone on a 2x DPR connection gets the 1200 version. A desktop gets the 2000 version. Saves bandwidth on mobile, saves CPU on desktop.

Format trade-offs

Resolution is one axis. Format is another. The matrix:

Format	Best for	Compression	Transparency	Animation
JPEG	Photos, complex images	Lossy, good	No	No
PNG	Graphics, screenshots, line art	Lossless, larger	Yes	No
WebP	Photos and graphics (modern replacement)	Lossy and lossless, both good	Yes	No
AVIF	Photos (best compression, less browser support)	Lossy, best	Yes	No
SVG	Icons, logos, simple graphics	Lossless, smallest for simple shapes	Yes	Yes (via CSS or JS)
GIF	Animation (legacy, replaced by video)	Lossless, large	Yes (1-bit)	Yes

The right format depends on the content:

• Photographs — JPEG for compatibility, WebP for better compression, AVIF for best compression (if you can afford the browser support gap).
• Graphics, illustrations, screenshots — PNG for quality, WebP for size. Most modern browsers support WebP lossless.
• Icons, logos — SVG. Period. The file is text, the resolution is infinite, the size is tiny.
• Animations — Video (MP4) for short clips, GIF only for legacy support, Lottie (JSON) for vector animations.

How to resize

The Uttir Image Resizer handles the resizing in your browser. The typical workflow:

1. Open the original image (the high-resolution source from the camera or design tool).
2. Set the target width (e.g. 1600 pixels) or target size (e.g. 2x of 800 CSS pixels = 1600).
3. Pick the output format (JPEG for photos, WebP for modern, PNG for graphics).
4. Set the quality (75-85% is the sweet spot for JPEG; 80% for WebP).
5. Download the resized image.

All of this runs locally. The image never leaves your device.

Image CDNs and automatic optimization

For high-traffic sites, the right approach is an image CDN that does the resizing and format conversion automatically:

• Cloudflare Images — automatic WebP/AVIF, on-the-fly resizing, URL-based params.
• Cloudinary — same, with more features and a higher price.
• Imgix — same, with a focus on real-time transformations.
• Vercel Image Optimization — built into Vercel deployments, automatic for Next.js images.

The CDN stores the original image, generates optimized versions on demand, and serves them with cache headers. The HTML uses the original URL; the CDN handles the rest.

The 80/20 of web images

For most sites, the right defaults:

• Hero images — 1920-2560 pixels on the long edge, WebP or AVIF, 75-80% quality.
• Content images — 1200-1600 pixels, WebP, 75-80% quality.
• Thumbnails — 400-600 pixels, WebP, 75-80% quality.
• Avatars — 200-400 pixels, WebP, 75-80% quality.
• Icons and logos — SVG (vector).

This produces images that look sharp on 2x DPR displays, load fast on 3G, and don't waste bandwidth on high-DPI mobile.

Common pitfalls

Uploading 4000-pixel-wide photos from a phone

A modern phone camera takes 12-50 megapixel photos. A 12 MP photo is 4032 × 3024. The file is 5-10 MB. The right target for a hero image is 1920-2560. The fix: resize with the Uttir Image Resizer before uploading.

Not using WebP or AVIF

WebP and AVIF give 25-50% smaller files than JPEG at the same visual quality. Every modern browser supports WebP. AVIF support is at 95% in 2026. The cost of supporting them is zero; the savings are significant.

Not lazy-loading below-the-fold images

Images that are not in the initial viewport should be lazy-loaded with the loading="lazy" attribute. The browser will defer downloading them until the user scrolls near them. For a long article with 20 images, this can save megabytes of initial bandwidth.

Not specifying width and height

Always set width and height on <img> tags. This prevents layout shift (the Cumulative Layout Shift metric in Core Web Vitals). Without explicit dimensions, the browser does not know how much space to reserve until the image loads, and the page jumps.

Forgetting alt text

Every <img> needs alt text. For decorative images, use alt="" (empty). For informative images, describe the content. The Uttir Image Resizer does not change the alt text, but the image quality and resolution affect whether the alt text accurately describes what the user sees.

Bottom line

For most web images, 2x DPR is the right target. Practical sizes: 1920-2560 for hero, 1200-1600 for content, 400-600 for thumbnails. Use WebP for modern browsers, fallback to JPEG for older ones. Resize before uploading — the Uttir Image Resizer does it in your browser. The right defaults make a page fast on 3G and sharp on Retina.