Google Play Feature Graphic: Size, Rules and Design Tips

The Google Play feature graphic is a 1024 × 500 px image, saved as a JPEG or a 24-bit PNG with no alpha channel, that every app must provide before its store listing can be published. Google shows it as the cover image for your preview video (with a play button over it), in large-format app collections including ads, and in large-format game recommendation groups.

The feature graphic size is the easy part. The hard part is that Google crops it, overlays UI on it, and shows it small, so the design has to survive all three. This guide covers the spec, where the graphic actually appears today, the safe zone, and the design patterns that hold up.

What is the Google Play feature graphic size and format?

The spec, per Google's preview assets help page, is short:

Two things trip people up. First, 1024 × 500 is not a common preset, so designs made at 1920 × 1080 and scaled down end up with squashed or cropped edges. Start the canvas at 1024 × 500 (or an exact multiple, such as 2048 × 1000, and export down). Second, many design tools export PNGs as 32-bit with an alpha channel by default, even when nothing is transparent. Play Console will refuse those. Export as JPEG, or turn off transparency in the PNG export settings.

For the full list of Android dimensions, including phone and tablet screenshots and the Android TV banner, see our App Store and Play Store screenshot sizes reference.

Where does the feature graphic appear on Google Play?

Older guides describe the feature graphic as a big banner at the top of every listing. That is no longer a reliable picture. Google's current help page lists three places:

• As the cover image for your preview video. If you add a YouTube preview video, the feature graphic is its poster frame. Whenever the video doesn't autoplay, Google overlays a play button on the graphic.
• In large-format app collections, including ads. Some Play surfaces show groups of apps as wide cards, and those cards use the feature graphic.
• In large-format game recommendation groups. For games, recommendation rows that mix preview videos and screenshots also show the feature graphic.

So the honest answer is: for an app without a preview video, many visitors to your listing may never see the feature graphic on the listing itself. It matters most when Google picks your app for a larger promotional format, which is exactly the situation where you want it to look good. And because it is required, it is worth getting right once rather than uploading a placeholder.

What is the feature graphic safe zone?

Google doesn't publish pixel measurements for the safe zone. The help page shows the cutoff zones as shaded areas on a diagram and gives the rule in words:

• Keep prominent visuals and the focal point towards the centre of the graphic.
• Don't place key elements (Google's examples: brand logo, app name, primary slogan and main UI) in the cutoff zones near the edges.
• Restrict background elements to the edges.
• Expect additional UI overlays in some formats, such as the play button.

Google is explicit about the stakes: failing to respect the focal point and cutoff zones "may result in ineligibility to appear in these formats." In other words, a graphic with the logo jammed into a corner won't get your listing rejected, but it can quietly cost you placement in the large-format collections.

A practical safe-zone rule of thumb

Since Google gives no exact numbers, we design to a conservative frame: anything that must be read sits in the central area of the canvas, with generous margins on all four sides, and nothing important sits where a round play button would land in the very middle. Fill the outer band with colour, texture or a cropped piece of UI that still looks fine if it's cut off. Then check the result by viewing it at roughly 300 px wide; if you can't read the words, they're too small.

How much text should a feature graphic have?

Less than you think. Google's store listing best practices say to "minimize your use of text" and to keep important elements toward the centre, and the preview asset guidelines warn against overloading the graphic with fine details that "will not be visible on many phone screens."

What tends to work:

• One line, two at most. The app name plus a short benefit line, for example "Budget in two taps" or "Plan meals for the week".
• Large type. If the graphic is shown at a third of its size, a 24 px font becomes 8 px. As a starting point, we'd keep headline type at 60 px or larger on the 1024 × 500 canvas.
• Localized text. Google recommends localizing graphic and branding text per market. If you can't maintain translated versions, a graphic with only your app name (which usually doesn't change) travels better than one with an English slogan.
• No repetition. Google's guidelines ask you to avoid duplicating messages across the short description, screenshots, feature graphic and video, since they may be shown side by side.

What not to put in a Google Play feature graphic

Google's preview asset guidelines list several elements to avoid in graphics. Some come from the binding Metadata policy; others are guidance that affects how your assets are promoted. Together:

The device imagery point surprises people, because a phone frame is the default move for App Store screenshots. On the feature graphic, Google would rather see your actual interface, illustration or brand world without a specific handset around it. If you want to show UI, crop a key screen and place it flat or slightly tilted without a bezel.

Feature graphic design patterns that hold up

From looking at a lot of Play listings while building Launch Shots, most good feature graphics fall into one of four patterns. Pick one; mixing them is where clutter comes from.

1. Brand mark on colour

Your logo or app name, centred, on a confident background colour pulled from the icon, with a subtle pattern towards the edges. It is the safest option: nothing important near the cutoff zones, no text to translate beyond the name, and it reads at any size. It suits utilities and apps whose name already explains the product.

2. Benefit line plus a slice of UI

A short benefit line on one side of the centre and a cropped piece of real interface (a chart, a card, a map) on the other, both inside the central area. This pattern does the most selling, so it fits apps where the UI itself is the proof, such as finance, fitness and productivity. Keep the UI crop large enough to recognise; a whole screen shrunk to fit is unreadable.

3. Illustration or key art

Games and content apps often use key art: characters, a scene, or a hero illustration with the logo in the middle. Game recommendation rows put the graphic next to videos and screenshots, so the centred focal point matters even more here. Make sure the characters' faces aren't on the edges where they could be cropped.

4. Video poster frame

If you have a preview video, design the feature graphic as its poster: a strong image with a clear empty area in the middle for the play button. Avoid placing the headline dead centre, where the button will cover it.

How to make a feature graphic

1. Set up a 1024 × 500 canvas (or 2048 × 1000 for working at 2×).
2. Mark a central safe area with guides and keep text, logo and UI inside it.
3. Pick the background from your icon palette, avoiding pure white, black or dark grey.
4. Add one line of text at most, in large type, then preview at about 300 px wide.
5. Export flat: JPEG, or PNG with transparency turned off.
6. Write alt text describing the graphic in a sentence.
7. Upload in Play Console under your main store listing, and add localized versions for languages where the text changes.

Any design tool can do this. If you're already producing your Play screenshots in a generator, it usually makes sense to build the feature graphic in the same place so the colours and type match. Our Play Store screenshot generator exports the feature graphic at the right size alongside phone and tablet screenshots, and direct upload to Google Play Console avoids the export-and-reupload loop. Plenty of teams do it in Figma or Canva too; the spec is the same either way.

Should the feature graphic match the screenshots?

It should feel like the same family, not a copy. Google recommends using similar or complementary elements, styles and colour themes across your listing graphics, and in the same breath warns against duplicating messages. In practice: same colours and typeface, different message. If your first screenshot says "Track every expense automatically", the feature graphic can carry the brand and a broader idea like "Money, sorted".

For the screenshot side of the set, our guides on how to make app store screenshots and screenshot best practices cover structure and headline copy, and most of it applies to Google Play too.

The short version

• Size: 1024 × 500 px. Format: JPEG or 24-bit PNG, no alpha. Required to publish.
• Shown as the video cover, in large-format app collections and ads, and in game recommendation rows.
• Everything important goes in the centre; edges are for background.
• One short line of large text at most, localized where it changes.
• No device frames, store badges, "#1" or "Free" claims, or calls to action.
• Match the screenshots' style, not their wording.
• Test variants with store listing experiments once the listing has traffic. If you want to try that on screenshots too, see how to A/B test store screenshots.