Back to Blog

Image resizing best practices: which pixel size to use

Resize to the largest size the image will actually be shown at, multiplied by the screen's pixel density, and no larger. For an image shown 700 CSS pixels wide, that means a file about 1,400 pixels wide, because most phones and many laptops draw two or more physical pixels per CSS pixel. Never enlarge a smaller original, keep the aspect ratio locked, crop before you resize, and compress as the last step.

The table below gives a starting size for common destinations. Where a platform publishes its own numbers, the table links them. Everything else is labelled as a SnapCompress recommendation, which means it follows from the rule above rather than from a platform's documentation.

Last updated:

Open the free resizer. It runs in your browser, so the image is never uploaded.

What size should I resize to?

DestinationResize toWhere the number comes from
Full-width hero image on a website1920 px wide, plus a ~960 px version for phones if you can use srcsetSnapCompress recommendation
Image inside a blog post or article column2 × the column width (a 700 px column needs ~1400 px)Pixel-density rule, see below
Card, thumbnail, or avatar2 × the size it is drawn atPixel-density rule
Photo sent as an email attachment for viewing on screen1600 to 2048 px on the long edgeSnapCompress recommendation
Image placed inside the body of an email2 × the width it appears at in the messagePixel-density rule
Shopify product photo2048 × 2048 px for square images; at most 5000 × 5000 px (25 megapixels) and under 20 MBShopify Help Center
Google Merchant Center product imageAround 1500 × 1500 px or larger; at least 500 × 500 px for all products from January 31, 2027; at most 64 megapixels and 16 MBGoogle Merchant Center Help
Instagram posts, Stories, and profile photosUse the crop presets, not a resizeInstagram image size guide

Two notes on the e-commerce rows. Shopify's 2048 px figure is what its help page says "usually displays best" for square images, not a requirement. Google's product data rules also say not to scale up an image or submit a thumbnail, which matters if your only copy of a product photo is small (Google Merchant Center Help).

For email, the limit that bites is usually file size rather than pixels. A personal Gmail account accepts 25 MB of attachments per message, and anything over that is replaced with a Google Drive link (Gmail Help). A few full-resolution phone photos can pass that on their own. The email image guide covers the rest of that workflow.

Why multiply by two? Device pixel ratio

Web layouts are measured in CSS pixels, but screens have physical pixels. The ratio between the two is window.devicePixelRatio. MDN describes a value of 1 as a classic 96 DPI display and 2 as the value expected on HiDPI and Retina displays, and notes that modern phones often report more than 2 (MDN: devicePixelRatio).

So an image laid out at 700 CSS pixels wide covers 1,400 physical pixels on a 2× screen. Give it a 700 px file and the browser has to stretch it, which looks soft. Give it a 4,000 px file and the browser throws most of those pixels away after downloading them.

Doubling is a practical ceiling for most content images. Going to 3× for phones that report 3 multiplies the pixel count by 2.25 compared with 2×, for a difference that is hard to spot on most content images. That trade-off is a SnapCompress recommendation, not a measured threshold. If you want both, serve two or three widths and let the browser choose with srcset. MDN's responsive images guide shows the syntax with 1x and 2x descriptors, and the Core Web Vitals guide covers srcset, sizes, and loading priority for the image that becomes your Largest Contentful Paint.

How to find the displayed size

Open the page in a desktop browser, right-click the image, and choose Inspect. The developer tools show the rendered size in CSS pixels when you hover the img element. Check it at the widest layout your site uses, since that is the largest the image will ever be drawn. Multiply by 2 and that is your export width.

Lighthouse does this check for you. Its "properly size images" audit compares each image's rendered size, adjusted for device pixel ratio, with the file's real size, and fails the image when the file is at least 4 KiB larger than needed (Chrome for Developers: Properly size images).

Why resize first, then compress?

Compression decides how many bytes each pixel costs. Resizing decides how many pixels there are. Halving the width and height leaves a quarter of the pixels, and that reduction costs nothing visible if the image was going to be drawn at the smaller size anyway. Compression alone, at the original size, has to remove detail to save the same space.

MDN's responsive images guide gives a concrete pair: the same picture is 128 KB at 800 px wide and 63 KB at 480 px wide (MDN). Exact savings depend on the content of the photo, so treat that as an illustration rather than a rule.

Shrinking an image with CSS, for example width: 300px on a 5,000 px file, does not help. The visitor still downloads every byte and the browser scales it down on screen. Lighthouse flags exactly this case.

A sensible order of operations:

  1. Edit and retouch the full-resolution original. Keep that file.
  2. Crop to the aspect ratio you need.
  3. Resize to the target size from the table above.
  4. Compress the result for its destination with the compressor.

Export from the original each time you need a new size. JPEG and lossy WebP lose a little detail on every save, so resizing a copy of a copy of a copy adds up.

Mistakes that make resized images worse

Upscaling

Enlarging an image cannot add detail that was never captured. The software invents the missing pixels by blending neighbours, so edges go soft and text gets blurry. If the only copy you have is smaller than the target, use it at its own size, find the original, or retake the photo.

Unlocking the aspect ratio

Typing both a width and a height that don't match the original's proportions stretches or squashes the image. If you need a different shape, crop first and then resize. For social formats with fixed ratios, the crop tool has presets for each Instagram format (for example Story, 9:16 and square, 1:1), and the Instagram image size guide explains which one to pick.

Confusing DPI with pixels

The DPI or PPI value stored in a file only tells a printer how large to print it. Screens ignore it and draw the image by its pixel dimensions. A 1,200 px image tagged 72 DPI and the same image tagged 300 DPI look identical on a website. When a web form asks for "high resolution", it means more pixels.

Picking the wrong output format

Resizing does not change what a format is good at. Photos belong in JPEG or WebP. Logos, screenshots, and graphics with flat colour or sharp text usually stay cleaner in PNG or lossless WebP. The JPEG vs PNG vs WebP comparison goes through the trade-offs, and the converter changes formats in the browser.

How SnapCompress resizes an image

This section describes what the /resize tool does, based on its source code (src/lib/image-processing/resizer.ts), so you know what to expect from its output.

  • Resampling. The image is decoded with createImageBitmap, which applies the photo's EXIF orientation so phone pictures come out upright. It is then drawn once onto a canvas at the target size with image smoothing on and imageSmoothingQuality set to "high". MDN lists the default for that property as "low" (MDN: imageSmoothingQuality). MDN only describes the values as low, medium, and high quality, without naming an algorithm, and marks the property as not Baseline, so the exact filter depends on your browser. The tool does not do multi-step ("step-down") resizing.
  • Output format. JPEG, PNG, and WebP files keep their format. Anything else the browser can decode is exported as JPEG, because canvas.toBlob only reliably writes a few formats and silently falls back to PNG for the rest (MDN: toBlob). DNG files, including iPhone ProRAW, are decoded first and exported as JPEG.
  • Quality. JPEG and WebP output is saved at quality 0.95. That keeps detail for a later edit but is not the smallest file, which is why the last step above is compression.
  • Limits. The resized image can be at most 4096 px on either side and 16 megapixels in total. Uploads are limited to 100 MB per file. Nothing leaves your device.

Step by step

  1. Open /resize and add an image.
  2. The tool opens on the Presets tab. Switch to Custom for the sizes in this guide and type only the width; with "Maintain aspect ratio" checked (the default), the height is calculated for you.
  3. Leave "Allow upscaling" unchecked. It is off by default, and with it off the tool refuses a target larger than the original instead of enlarging it.
  4. Click Resize Image, compare the before and after, and download.
  5. Run the download through the compressor if it is going on a website or into an email.

The other two tabs have narrower uses. Percentage shrinks by a fixed factor, which is handy when you don't know the exact target. Presets fits the image inside a fixed box such as 1920 × 1080 while keeping its proportions, but unlike Custom it does not block enlargement, so check that your original is bigger than the preset. Presets also don't crop: an Instagram preset in /resize gives you an image that fits inside 1080 × 1350, not one that fills it. For an exact Instagram frame, use the crop tool.

Quick checklist

  • Where will this image be shown, and how wide is it drawn there in CSS pixels?
  • Is the export width about twice that, and no larger than the original?
  • Is the aspect ratio locked, and did you crop before resizing?
  • Did you export from the original rather than an earlier export?
  • Did you compress the resized file before publishing or sending it?

Sources

Further reading