Play Store Feature Graphic vs Screenshots: 1024×500 Specs

The Play Store feature graphic is a single 1024 x 500 px banner image, JPEG or 24-bit PNG (no alpha), and it is required to publish your store listing [1]. Screenshots are a separate asset set: 2 to 8 per device type, anywhere from 320 px to 3,840 px on any side, with the longest side capped at 2x the shortest [1]. The feature graphic is displayed before your screenshots in the listing and serves as the cover image when you link a promo video [1]. Different file, different rules, different role.

TL;DR:

• The feature graphic is required to publish. Screenshots are conditionally required: minimum 2 to publish; minimum 4 at 1080 px+ for store recommendation eligibility [1].
• Feature graphic specs: exactly 1024 x 500 px, JPEG or 24-bit PNG (no alpha) [1]. There is no "minimum" or "maximum" because the dimensions are fixed.
• Screenshot specs: 320 px to 3,840 px on any side, longest side under 2x shortest, JPEG or 24-bit PNG (no alpha), 16:9 or 9:16 [1].
• When you link a YouTube promo video, the feature graphic becomes the video's cover image with a play button overlay [1] [3]. Keep the center clear of critical text.
• Google bans specific phrases on feature graphics that screenshots can also be flagged for: "App of the year", "#1", "Best of Play 20XX", "Popular", "10% off", "free for a limited time only" [2].
• Treat the feature graphic as Frame 0: it's the first asset a Play Store visitor sees, before any screenshot, and its job is hook + brand recognition, not feature explanation.

This post sits inside the Google Play screenshot sizes 2026 pillar, which covers every screenshot dimension by device type. The pillar answers "what size is a phone screenshot, a tablet screenshot, a Wear OS screenshot." This post answers "how is the feature graphic a different asset, and when do you need each." For the cross-platform launch perspective (where iOS and Android diverge on store-listing assets), see Play Store vs App Store: key differences for indie devs.

Table of Contents

• What is the Play Store feature graphic?
• How do feature graphic specs differ from screenshot specs?
• When does Google show the feature graphic vs your screenshots?
• What happens to the feature graphic when you add a promo video?
• Which content rules apply to feature graphics that don't apply to screenshots?
• Should you treat the feature graphic as Frame 0?
• Takeaways

What is the Play Store feature graphic?

The Play Store feature graphic is a 1024 x 500 px banner image that Google requires every published app to upload. It appears at the top of your store listing, above your screenshots, and is also used in various promotional placements Google controls [1]. You upload it inside the Play Console under your app's Main Store Listing tab, alongside (but separate from) the screenshot uploader.

The asset has a fixed footprint. Unlike screenshots, where you can pick anywhere in the 320-3,840 px range, the feature graphic is exactly 1024 px wide by 500 px tall. Google rejects uploads that miss the dimension by even one pixel. JPEG or 24-bit PNG only; transparency (alpha channel) gets rejected at upload [1] [4].

The role of the feature graphic is to act as the cover or banner for your entire listing. It is the first piece of visual content a user sees when they land on your Play Store page, and the only asset Google can promote independently of your screenshots (for example, in editorial collections, "Recommended for you" carousels, and the homepage feature placements that the feature-graphic asset was originally named for). Screenshots, by contrast, only appear inside your own listing's screenshot gallery and never as standalone promotional surfaces [3].

How do feature graphic specs differ from screenshot specs?

The two assets follow different rules across every spec dimension. Side by side:

The dimensions are the most visible difference. A feature graphic is a fixed wide landscape banner. Screenshots are the device's native ratio, almost always portrait, almost always 9:16 (about 96% of top-charting apps ship portrait per app industry analysis [4]). You cannot reuse a screenshot as a feature graphic or vice versa; the ratios are incompatible.

The quantity difference matters for production planning. Feature graphic is one image per language. If you're localized into 10 languages, that's 10 feature graphic files. Screenshots multiply: 8 phone slots x 10 languages = 80 phone files alone, then tablet, then Wear OS. The feature graphic's single-asset-per-locale shape makes it the cheapest piece of the localization stack to produce.

For the per-device pixel reference (phone, tablet, Wear OS, Android TV) used inside the free device dimensions tool, the Google Play screenshot sizes pillar lays out every spec per device class.

When does Google show the feature graphic vs your screenshots?

The two assets appear in different parts of the Play Store UI. Knowing which surfaces show which asset changes how you design each.

The feature graphic appears:

• At the top of your store listing on phones, tablets, and the web Play Store [1].
• As the cover image for your preview video when one is linked, with a play button overlaid on top [1] [3].
• In Google-controlled editorial and promotional placements (collections, "Editor's Choice" pages, homepage features). Google promotes apps using the feature graphic asset, not screenshots, in these surfaces [3].
• In some "Recommended" and "Suggested for you" carousels that show a single banner per app.

Your screenshots appear:

• Inside your store listing only, in the screenshot gallery below the feature graphic [1].
• Up to 8 frames per device type, scrolled horizontally by the user [1].

The key implication: your feature graphic is the only one of your assets Google can use to promote your app independently. If you get featured in an editorial collection, the feature graphic is what the editor's surface shows. If your app pops into a "Recommended" carousel, the feature graphic is the card. Your screenshots only earn impressions from users who already clicked into your listing.

This is the asymmetry that makes the feature graphic punch above its weight on conversion. The first screenshot drives in-listing conversion (users who already arrived). The feature graphic drives top-of-funnel clicks (users who haven't arrived yet). Both matter, but they earn impressions from different traffic sources.

What happens to the feature graphic when you add a promo video?

When you link a YouTube promo video to your store listing, the feature graphic's role shifts. Google overlays a play button on top of the feature graphic, and the combined image becomes the entry point users tap to watch the video [1] [3]. The video itself must be a YouTube URL set to public or unlisted, with ads disabled, no age restrictions, and embedding enabled [1].

Three implications follow from the play button overlay.

Implication 1: Center placement of text and key visuals gets risky. The play button sits roughly in the center of the feature graphic, with apptamin's analysis noting that the button covers a meaningful portion of the central area and that the bottom-right corner is also affected on some surfaces [3]. Important text or product imagery placed in the dead-center area gets obscured. Push the headline copy and product visuals toward the left third or right third of the graphic instead.

Implication 2: The feature graphic now has to work two jobs. Without a video, it's a static banner. With a video, it's also the video's pre-play thumbnail. A composition that reads well as a banner can read badly as a thumbnail (and vice versa) depending on where the play button lands.

Implication 3: If you set a custom YouTube thumbnail, that thumbnail can take over instead. Per apptamin's reporting, when a YouTube video is linked and the YouTube channel has set a custom thumbnail, the Play Store may use the YouTube thumbnail in place of your feature graphic as the video cover [3]. To control what users see, either match your YouTube thumbnail to your feature graphic, or skip the YouTube custom thumbnail entirely so the Play Store falls back to your feature graphic.

For the preview video specs themselves (length, format, autoplay behavior), the App Preview Video Specs tool covers iOS and the App Store preview videos 2026 conversion guide covers the conversion side. The Play Store specifics: the first 30 seconds of your video autoplays in the listing [1], so the opening seconds carry the most weight.

Which content rules apply to feature graphics that don't apply to screenshots?

Both assets follow Google's general metadata policies, but the feature graphic gets called out specifically in the store listing best practices doc for content patterns that get rejected [2]. The list of explicitly banned content:

• Award and ranking claims. "App of the year", "#1", "Best of Play 20XX", "Popular", and award icons are all banned on feature graphics [2]. Google's reasoning is that these claims look like endorsements by Google itself, and rankings that change over time make the asset stale.
• Pricing language. "10% off", "$50 cash back", "free for a limited time only" are explicitly listed as banned [2]. Pricing changes and the asset doesn't update with it, so Google blocks the pattern.
• Misleading icons. Imagery that resembles existing well-known products triggers rejection on a "misleading users" basis [2].
• Excessive text. Google's guidance is to "minimize your use of text" on feature graphics and "design for scale and keep important elements toward the center" [2]. Text that looks fine at full Play Store resolution becomes illegible on phone-sized surfaces.

Screenshots are not subject to the same award/pricing/text bans at the same enforcement strictness. You can put "Trusted by 100,000 users" on a screenshot caption (factual claim, not a Google endorsement) and it won't trigger rejection. The same line on a feature graphic risks getting flagged as a "Popular"-style ranking claim. The implicit rule: anything that reads like Google itself promoted the app belongs nowhere near the feature graphic.

For the broader compliance picture across both stores, the App Store rejections screenshot compliance guide covers the common rejection patterns on the iOS side, most of which apply to Android with minor variation.

Should you treat the feature graphic as Frame 0?

Yes, with one caveat. The "Frame 0" framing comes from indie ASO playbooks and shows up briefly in our App Store screenshots that convert design guide. The framing is correct: the feature graphic is the first asset a Play Store visitor sees, it sits above your screenshots in the visual hierarchy, and on mobile listings it's the only asset visible above the fold before the user scrolls. Treating it as the zero-index frame of your visual story is the right mental model.

The caveat: Frame 0 has a different job than Frame 1. Frame 1 (your first screenshot) carries the burden of explaining what the app does. The feature graphic carries the burden of getting the visitor to care in the first place. Designing a feature graphic that explains the app the way a screenshot does (UI imagery, feature callouts, dense copy) wastes the slot. Designing it the way you'd design a magazine cover (clear brand mark, one strong visual, minimal text, emotional pull) uses the slot the way Google's editorial team uses it when they promote apps.

The split that works for most indie apps:

• Feature graphic (Frame 0): brand mark, one hero visual, 3 to 5 words of headline copy maximum. The job is hook + recognition.
• First screenshot (Frame 1): the strongest single feature the app delivers, with a caption that names the keyword you most want to rank for. The job is "this is what the app does."
• Screenshots 2 and 3 (Frames 2 and 3): the next two strongest features. The job is "and it also does this and this."
• Screenshots 4 through 8: filler reinforcement plus social proof, optional video, lifestyle/context shots. The job is depth and completion.

The Wear OS, TV, and tablet variants each get their own screenshot sets, but only the feature graphic is shared across all device-type listings on the same app. One feature graphic, many screenshot sets.

Takeaways

The two assets are not interchangeable, and treating them as variations on the same theme is the most common feature-graphic mistake on the indie side.

• The feature graphic is required to publish, screenshots are conditionally required. You can't ship a store listing without a feature graphic [1]. You can technically ship with just 2 phone screenshots, though Google's recommendation eligibility threshold is 4 at 1,080 px+ [1].
• Dimensions are different by an order of magnitude. Feature graphic: fixed 1024 x 500 px. Screenshots: 320 to 3,840 px on any side, longest under 2x shortest [1]. You cannot reuse one as the other.
• The feature graphic is the only asset Google can promote independently. Editorial collections, "Recommended for you", homepage features all use the feature graphic, not screenshots [3]. Screenshots only earn impressions inside your own listing.
• A linked promo video changes the feature graphic's job. Play button overlay, center area obscured, YouTube custom thumbnail can override the Play Store feature graphic [1] [3]. Plan composition around the play button or skip the YouTube custom thumbnail.
• Content rules are stricter on feature graphics. Bans on "#1", "App of the year", "Popular", pricing claims [2]. Screenshots get more latitude on factual social proof.
• Frame 0 thinking works. Feature graphic = hook + recognition. First screenshot = feature explanation. Different jobs, different design.

For the full Play Store screenshot spec sheet across every device class, the Google Play screenshot sizes 2026 pillar is the upstream reference. For the cross-platform launch view (iOS vs Android store-listing asset differences), Play Store vs App Store: key differences for indie devs is the sibling. For the Samsung-specific frame on the screenshot side, the Samsung Galaxy S25 Ultra mockups page is the Android-phone CORE surface.

We built Try AppScreenshotStudio today for free so the production side of this stack (1 feature graphic + up to 8 phone screenshots + tablet variants, across as many languages as you ship) is one upload and one set of decisions, not dozens of separate Figma files. The spec differences explained above are baked into the generator: feature graphic templates use the 1024 x 500 frame, screenshot templates use the per-device dimensions, and the localization layer multiplies both at the same time.