Where does Google Play actually show your feature graphic?

Play Console won’t publish your store listing until you upload a 1024×500 feature graphic, so every Android developer makes one, usually an hour before launch, usually by laying the app icon over a gradient. Then most of us never see it again. Screenshots sit in a fixed row on your listing; the feature graphic doesn’t have one fixed spot. Here is where Google says it goes, what that means for how you design it, and the export detail that gets it refused.

The three places Google names

Google’s own preview assets help page is short on this, and specific. The feature graphic appears in three kinds of placement:

As the cover of your preview video, if you have one. Play overlays a play button on the graphic, and tapping it starts the video. With a video attached, the graphic stops being a banner and becomes a thumbnail whose one job is to earn the tap.

In large-format app collections, including ads. For apps, Google shows some collections as big cards instead of icon rows, and your feature graphic is the card. You don’t choose when that happens. Google does.

In recommended-games groups, for games. Games get large-format groups that combine preview videos, screenshots and the feature graphic.

Notice what the page doesn’t say. It never promises the graphic appears on your own listing when you have no video, and Play’s listing layout has changed across redesigns. So don’t design it on the assumption that it’s your listing’s banner. Design it for the placements Google does describe: a card in a feed, next to other apps’ cards, or a video cover with a button on top.

Why it’s required if it might not show

The help page is blunt: “You must provide a feature graphic to publish your store listing.” The requirement makes sense once you see the placements. Large-format collections are Google’s editorial and ad surfaces, assembled without asking you, and they need a wide image from every app that might land in them. If yours is a placeholder, it’s the placeholder that appears on the day your app gets its biggest card.

That’s the real argument for caring about an asset you rarely see. The moments when it does show tend to be the high-traffic ones: a collection, an ad, a video somebody was about to watch.

Design for the crop, not the canvas

Google’s design guidance is mostly about surviving formats you can’t preview. Keep prominent visuals and the focal point towards the center. Keep the logo, app name, slogan and main UI out of the “cutoff zones”. Expect that “some formats may use additional UI overlays”. Restrict background elements to the edges.

The cutoff zones are drawn as red areas on a diagram, and the page gives no pixel values for them. So the honest approach is to plan for the worst crop you can imagine. Our working rule, which is ours and not Google’s: anything that must survive goes inside the middle 60% of the width and the middle 70% of the height, and everything outside that is allowed to be pure atmosphere: gradient, texture, the edge of a device screen running off-canvas.

Then think about size. A 1024-pixel-wide file shown as a card roughly 340dp wide (a plausible phone card after margins; Play doesn’t publish card widths) is drawn at about a third of its file size in dp. A headline set 40 pixels tall in your design file ends up around 13dp on screen, which is body-text size. If you want a line of text to read like a headline in a feed, its capitals need to be something like 90 to 120 pixels tall in the file, which leaves room for about four or five words. That’s also why Google warns against fine detail: everything in the file shrinks by the same factor.

And the graphic isn’t exactly 2:1. 1024×500 is 2.048:1, so a 2:1 artboard exported at 1024×512 or 2000×1000 is the wrong shape, and Play Console won’t take it. Build the artboard at 1024×500 (or 2048×1000 if you like working at 2×, then export at 1024×500) and you’ll never have to think about it again.

What Google tells you to leave off

The guidance has a list of things to avoid, and several are easy to do by accident:

Promotional words. “Best”, “#1”, “Top”, “New”, “Free”, “Discount”, “Sale” and “Million Downloads” are all named, along with anything time-sensitive. A graphic that says “New for 2026” is out of date by spring and against guidance from day one.

Device imagery, store badges and third-party trademarks. Your app’s UI is fine. A photo of a specific phone, a “Get it on Google Play” badge, or someone else’s logo is not.

A copy of your icon. Google says branding that closely mirrors the icon causes duplication. The lazy default of icon-on-gradient is exactly that.

Pure white, black or dark grey backgrounds. They blend into the Play Store background, so the card loses its edge. That one stings for us: ShotCanvas’s own brand is gold on true black. A dark brand doesn’t have to give up its colour for this. Lift the background a few steps toward a tinted colour, or put a lighter field behind the focal point so the card reads as a shape against the page.

The export trap: “no alpha” means no alpha channel

The spec says JPEG or 24-bit PNG, no alpha. Most people read that as “don’t use transparency” and move on, because their graphic is fully opaque. But many tools write a 32-bit RGBA PNG whether or not any pixel is transparent. A browser canvas always does. App Store Connect checks the file, not the pixels, and Google’s spec is worded the same way.

We learned this the expensive way in ShotCanvas’s own publish flow: canvas-rendered PNGs were rejected by App Store Connect for having an alpha channel, though every pixel was opaque. We now flatten every image onto an opaque canvas and upload JPEG, which can’t carry alpha at all. Google’s spec has the same rule, so the same fix applies.

Checking takes one command. On a Mac, sips -g hasAlpha feature.png answers yes or no. I generated a fully opaque 1024×500 RGBA PNG to test it: sips reported hasAlpha: yes, and file reported 8-bit/color RGBA. Converting with sips -s format jpeg feature.png --out feature.jpg produced a three-component JPEG at the same 1024×500, with hasAlpha: no. A solid-colour or photographic feature graphic loses nothing visible at a sensible JPEG quality.

Treat it like the other listing assets

Three habits that cost little and are easy to forget:

Localise it. Google recommends localising the graphic and any text on it for each market. If your screenshots are translated and your feature graphic is English, the first image a German user sees in a large card is the one you didn’t translate.

Write the alt text. Play asks for alt text on graphic assets: 140 characters or fewer, and don’t start with “image of” or “photo of”, because screen readers already announce that. Describe what the graphic shows that matters, not the colours.

Test it. Play’s store listing experiments can test the feature graphic against your current one, and custom store listings can swap it per country or campaign. If you have a preview video, the graphic is its cover, so test it on the metric that matters there: whether people press play.

The rest of the listing

The ShotCanvas app’s Play release checklist flags a listing that’s missing a feature graphic, along with the icon and the two-screenshot minimum, before you try to publish. The screenshots that sit beside the graphic are what ShotCanvas designs: one visual system, exported at exact store sizes, and published straight to Play as flattened, opaque images, so the alpha trap above never comes up.