Image sizes for every platform: a practical reference

Most advice about image dimensions is a list of numbers with no explanation, which is why it goes out of date and why people keep looking it up. The numbers do matter, but there is one principle underneath them that makes most of the list unnecessary.

The rule that replaces the list

An image needs enough pixels to cover the space it occupies on screen, multiplied by the pixel density of the screen showing it.

That is the whole thing. Everything below is that rule applied to specific cases.

The multiplier is the part people miss. Phones and modern laptops pack two or three physical pixels into each CSS pixel — a "2x" or "3x" display. An image displayed in a 600-pixel-wide column looks soft on those screens unless the file contains roughly 1,200 pixels of actual width.

So: measure the display width, double it. Beyond about 2x there is very little visible benefit and a real cost in file size, which is why 3x is rarely worth targeting.

Anything larger than that is bytes the visitor downloads and never sees. A 4000-pixel photograph in an 800-pixel column wastes roughly 96% of its data.

Website images

Height is usually whatever the aspect ratio produces. Constraining both dimensions is only necessary when the layout demands a fixed shape, and in that case crop rather than stretch.

Social platforms

These change, so treat them as current-generation rather than permanent. The aspect ratios are far more stable than the pixel counts.

The 1200 × 630 figure is worth memorising because it is effectively the universal link-preview size. Facebook, X, LinkedIn, WhatsApp, Slack and most other platforms read the same Open Graph tags and expect roughly that shape. One image at that size covers nearly everything.

Why 1200 × 630 specifically

It is a 1.91:1 ratio, which is close to the golden-ratio-ish shape that reads well as a horizontal card. The pixel count is large enough for a 2x display at typical card widths and small enough to load quickly on a link preview, which is fetched by a bot rather than a browser and needs to be quick.

Two practical constraints when designing one. Keep important content — text, faces, logos — away from the edges, because different platforms crop slightly differently and a headline that ends at the boundary will lose its last word somewhere. And keep text large: link previews are frequently displayed at a few hundred pixels wide, where anything smaller than about 40px in the source becomes unreadable.

Email

Email is the most constrained environment and the one where the numbers are least negotiable.

Maximum width: 600 pixels. This has been the standard for two decades and is still right — it is roughly what fits in a desktop email client's reading pane without horizontal scrolling.

For high-density screens, that means a 1200-pixel file displayed at 600. Set the width explicitly in the HTML, because email clients handle images inconsistently and an unconstrained image will break the layout somewhere.

Keep the total message weight down. Gmail clips messages over about 102KB of HTML, and while images do not count toward that, a slow-loading email is a poorly-performing one. Many recipients also have images blocked by default, so nothing important should exist only inside an image.

Print

Print works in physical dimensions and DPI rather than pixels, which is a different mental model.

300 DPI is the standard for quality printing. To find the pixels you need: multiply the printed size in inches by 300.

• Business card (3.5 × 2 inches): 1050 × 600 pixels
• A4 full page (8.3 × 11.7 inches): 2480 × 3508 pixels
• 6 × 4 photo print: 1800 × 1200 pixels

150 DPI is acceptable for large-format work viewed from a distance — posters, banners — where nobody examines it from 30cm away.

Two things that differ from screen work: use CMYK if your printer asks for it, since screen colours are RGB and some vivid colours cannot be reproduced in ink. And avoid JPEG for anything with text or sharp edges, where compression artefacts become visible in print far more readily than on screen.

Downscale freely, upscale reluctantly

The asymmetry here explains a limit no tool works around.

Downscaling combines several source pixels into one output pixel. The information needed to decide each output value genuinely exists, so the result is an accurate summary of the original — it looks good.

Upscaling has the opposite problem. Doubling an image's width means three quarters of the output pixels correspond to nothing that was ever captured, and their values are estimated from neighbours. Estimation is why enlargements look soft: the invented pixels are averages, and averages have no edges.

Machine-learning upscalers improve on this by predicting plausible detail rather than averaging, but they are inventing a convincing guess rather than recovering the original. For anything where accuracy matters — a document, a product photograph — starting from a larger original is the only real answer.

Practical consequence: always keep your originals, and derive every size from them rather than from a file you already reduced.

Order of operations

If you are preparing images properly, the sequence matters.

1. Crop to the shape you need, before anything else. 2. Resize to the target dimensions. This is the largest file-size saving available and costs no visible quality. 3. Convert format if needed — WebP for the web in most cases. 4. Compress last, checking the result at full size.

Doing it in this order means each step operates on the smallest sensible input. Compressing a 4000-pixel image aggressively and then resizing it means you kept the compression artefacts and threw away the pixels.

The resizer handles batches with a "fit inside a box" mode, which is the one you want for mixed portrait and landscape images — setting a width forces portraits to be very tall, whereas fitting inside a box constrains whichever dimension is larger. The compressor can target a specific file size when an upload form imposes a limit.

What to do when you cannot decide

If you are preparing one image and do not know where it will end up, 1600 pixels on the longest side, saved as WebP at around 80% quality is a sensible universal answer. It is large enough for a 2x display at typical article widths, small enough to load quickly, and downscales cleanly to anything smaller.

Keep the original somewhere. Everything else can be regenerated from it.