How to Read a Platform's Image Requirements

Why the numbers you find are usually wrong

Platform image specifications change frequently and quietly. A layout redesign alters how images are cropped; a new surface appears with different proportions; a recommended size is adjusted for higher-density displays. None of this is announced in a way that reaches the many articles listing the old numbers.

Those articles then persist indefinitely, well ranked and confidently worded, long after they stopped being accurate. The ones that carry a recent date frequently have an updated date on an unchanged body. There is no reliable way to tell from the outside which numbers are still current.

The behavior also varies by context within a single platform. One image may be displayed as a wide banner in one place, a square in another, and a small circle in a third, each with its own crop. A single recommended dimension cannot describe all of them, so any article giving one number per platform is simplifying past the point of usefulness.

This guide therefore gives no dimensions. Numbers stated here would be wrong by the time you read them, and a guide that is confidently wrong is worse than one that tells you where to look.

Where the current requirements actually live

Start with the platform's own help centre, searching for image sizes or media specifications. This is maintained by the people who change the behavior and is the closest thing to authoritative.

For anything involving how a link preview appears, the developer documentation is usually more precise than the consumer help pages. Platforms that support link previews publish the metadata tags they read and the image sizes they expect, because they need developers to get it right.

Many platforms provide a preview or debugging tool that shows exactly how a given page or image will be rendered. These are the most reliable source of all, because they exercise the real code rather than describing it. When one exists, use it in preference to any documentation.

For advertising formats, the ad platform's own specifications are separate from the organic ones and are usually stricter, with explicit rules about dimensions, file size, and sometimes the proportion of the image that may contain text.

Finally, test with a real post. Upload the image, look at it in the feed on a phone and on a desktop, and check the thumbnail. This catches things documentation does not mention.

Designing for an unknown crop

Since you cannot control how every surface will crop your image, design so that it does not matter. The technique is a safe area: a region in the middle of the frame containing everything essential, surrounded by margin you are content to lose.

Anything that must survive — a face, a logo, a headline, a call to action — belongs inside the safe area. Anything at the edges should be background, texture, or scenery. An image built this way works as a wide banner, a square, and a circular avatar without three separate versions.

Keep text well inside the frame and larger than feels necessary. Text near an edge is the first casualty of a crop, and text sized for a desktop view is frequently illegible in a feed thumbnail on a phone. If the words matter, they need to work small.

Be especially careful with circular crops, which profile images often receive. A square logo with content in the corners loses those corners entirely when a circle is inscribed in it.

Where a platform genuinely displays one image at two very different aspect ratios, produce two deliberate crops rather than accepting a compromise that is poor in both places.

What happens to your file after upload

Platforms re-encode uploaded images to their own specifications. Whatever quality setting you chose is replaced by theirs, and a lossy image is compressed again on top of the compression it already had.

This has a practical consequence that runs against instinct: uploading a heavily compressed file is worse than uploading a clean one, because the platform's encoder then works from damaged input and compounds the artifacts. Upload a good-quality file at appropriate dimensions and let the platform do its own compression once.

Uploading something enormous is not better either. A file far larger than the platform will display is downscaled by their pipeline with settings you do not control, and the upload is slower for no benefit. Matching their recommended dimensions reasonably closely gives their encoder the easiest job.

Many platforms also strip metadata on upload, which is usually welcome for privacy and occasionally unwelcome if you rely on embedded copyright or attribution information. Do not assume either behavior; if attribution matters, it needs to be visible or asserted elsewhere.

Some platforms convert formats entirely, turning a PNG into a JPEG for instance, which will flatten any transparency onto a background colour of their choosing. If transparency matters, check what actually happens rather than assuming it survives.

Link previews on your own site

When a page from your site is shared, the preview image comes from metadata tags in the page rather than from anything chosen at share time. Getting these right means the preview looks deliberate instead of arbitrary.

The Open Graph protocol is the widely implemented convention, read by most platforms that render link previews. It specifies tags for the title, description, and image, and platforms generally fall back to it even when they also support their own variants.

Provide an absolute URL for the preview image, not a relative one — the platform fetching it has no way to resolve a relative path. Declaring the image's dimensions in the accompanying tags helps some platforms render the preview before they have finished downloading the file.

Preview images are cached aggressively by the platforms that fetch them. Changing the image on your page frequently does not change an already-cached preview, which is a common source of confusion. Most platforms provide a debugging tool that re-fetches the page, and that is the correct way to refresh it.

A workable process

Check the platform's own documentation for the surface you are targeting, and use their preview tool if one exists. Do this at the start of a project rather than relying on what you remember from last time.

Design with a generous safe area so the artwork survives crops you did not anticipate. Keep essential content and text well inside the frame and larger than feels necessary.

Export a clean, appropriately sized file — good quality, right dimensions, correct format — and let the platform re-compress it once rather than handing it something already damaged.

Verify on a real post, on a phone as well as a desktop, across the feed view, the thumbnail, and the full view. The upload preview is not a reliable guide to any of them.

Keep the source file. When the platform changes its layout, which it will, you will want to re-export rather than re-create.