App Screenshots Are the Wrong Shape for Every Ad Platform

A phone screenshot comes out of the device at 1080 by 2400 pixels — a ratio of 0.45, tall and narrow, exactly the shape of the phone that took it. Four of our store-promo posts sat blocked last week on precisely this number, because the platform we were posting to does not accept it.

The window, not the screenshot, is what matters

X’s accepted image ratio range runs from 1.0, square, through to 1.91, landscape. A raw phone screenshot, at 0.45, is not close to either edge of that window. It is roughly half again narrower than the platform’s most forgiving format, square, and nowhere near the wide landscape shape the platform actually favours for a promotional image in feed.

This is not a defect in the screenshot. A phone screenshot is exactly the right shape for the thing it is a record of — what an app looks like on a phone screen. It is simply the wrong shape for a feed post on a platform designed around a horizontal or square frame, and no amount of the screenshot being a good screenshot changes the ratio it was captured at.

The worse discovery underneath

Four posts blocked on aspect ratio would have been a straightforward fix — crop each one, ship it. What we found instead, checking the four images against each other before cropping any of them, was that three of the four were byte-identical. Not visually similar: three separate posts, meant to promote three separate features, were carrying the exact same file, confirmed by comparing SHA-256 hashes rather than eyeballing thumbnails that all look roughly alike at small size.

Had we cropped and shipped without checking, we would have solved the aspect ratio problem and created a worse one: the same picture, re-cropped into the correct ratio, published three times under three different captions on one account, in the same week. The platform would have accepted every one of those posts. Nothing about a correctly-shaped duplicate trips any validation a platform runs, because aspect ratio and byte-for-byte sameness are unrelated checks, and most pipelines only run the first one.

What we built instead

Four distinct 1600 by 900 cards, one per theme, each one a purpose-built image for the specific feature or angle the post was promoting rather than a recycled screenshot pushed through a crop tool. Landscape at that resolution comfortably sits inside X’s accepted window and most other platforms’ as well, and building four originals rather than four crops of the same source is what actually guarantees four different images rather than four different frames of one.

We verified the fix the same way we found the problem: hashing all four finished files and confirming none of them matched. That check takes seconds and it is the only way to be certain a fix like this actually produced distinct assets rather than four files that merely look different when viewed one at a time.

Every platform has a window, and your source rarely sits in it

X’s 1.0 to 1.91 range is one platform’s answer to a question every platform answers slightly differently. Instagram feed, Instagram Stories, Facebook feed and the various app store promotional slots each define their own accepted ratio window, and none of them are shaped like a phone screenshot, because none of them were designed around one.

A phone screenshot is 0.45. A desktop screenshot is a different, usually wider ratio again. A hero photo from your website is whatever your designer chose it to be. None of these source assets were created with any particular ad platform’s window in mind, because they were created for a different purpose entirely — showing what the app or the site actually looks like — which means the near-universal case, not the exception, is that whatever image you already have on hand needs deliberate re-creation for the platform you are about to post it to, not a quick crop.

The crop is the tempting shortcut, and it is also where duplication hides, because a crop of an existing file preserves whatever was already wrong with that file, including, in our case, the fact that it was the same file as two other posts already queued to go out.

Why a hash and not a glance

We compared SHA-256 hashes rather than looking at the four images side by side, and that choice is not incidental. Three of the four files were similar enough in subject that a quick visual pass across four small thumbnails is exactly the situation where a human reviewer says “close enough, ship it” without registering that two of them are not merely similar but identical down to the byte. A hash comparison has no opinion about whether two images look alike. It either matches or it does not, and there is no version of “close enough” available to it.

That matters here specifically because the failure mode was not a subtly different crop or a slightly different colour grade — it was the literal same file, saved under three different names, referenced by three different posts. A difference that total is invisible to a glance across thumbnails and immediate to a hash comparison, which is precisely the gap a manual review step reliably misses and an automated one reliably catches.

The checklist that would have caught this earlier

Check the target platform’s accepted aspect ratio window before building anything, not after a post gets rejected. Build source images at a ratio inside that window rather than cropping down from whatever asset already exists. Hash every finished image before it ships, and compare the hashes against each other when more than one image is queued for the same account in the same period. That last step is cheap enough to run every time, and it is the only one of the three that would have caught our actual problem, since the aspect ratio issue was visible immediately and the duplication was not.

If your own store-promo or ad creative pipeline is pulling from phone screenshots or existing site photography without checking against the platform’s own accepted window, that is worth auditing before the next batch goes out rather than after four posts sit blocked. We wrote about a related image problem, app store listing assets, on our own site earlier this year — same root cause, a pipeline that checked one thing and not the other. Our app store optimisation basics and our what the Play Store asks for cover the sourcing side of this; getting the format right once you have the source is what our web design work handles as a matter of course.

---

Ashish Ganda is the founder of Cosmos Web Tech, which builds and maintains websites for small businesses across Western Sydney and the Hills District.

Case studies of app work like this are on the Awesome Apps site.