Store Listing Screenshots and Promo Images

A listing with one blurry screenshot of a settings page converts poorly; a listing whose images claim features the extension does not have gets rejected for misleading content. Store images are the first — often the only — thing a potential user looks at before deciding to install, and each store has its own required sizes and rules. Extensions add a twist: the product’s UI lives partly in the browser’s chrome (popup, side panel) and partly on other people’s websites, both of which need care to show honestly and legally. This guide covers sizes, content, automated capture and the policy traps. It belongs to store submission and permissions compliance.

What each store asks for

The Chrome Web Store requires a 128×128 store icon, at least one screenshot (up to five) at 1280×800 or 640×400, and a 440×280 small promotional tile; a 1400×560 marquee image is optional and used if the item is featured, and a YouTube video can be linked. Microsoft Edge Add-ons asks for similar assets with its own size list in Partner Center. Firefox Add-ons (AMO) accepts screenshots of various sizes, recommending a 1.6:1 ratio such as 1280×800, plus the add-on icon. Safari extensions are listed as part of a Mac or iOS app, so App Store Connect’s app screenshot sizes apply to the containing app. Reusing one well-made 1280×800 set covers most of these with only crops and exports.

Step-by-step: images that convert and pass review

1. Plan one screenshot per job the extension does

1screenshots.md
21. Hero: the core action in context — article page + popup "Summarise" with result
32. Feature: highlights on a page + side panel notes
43. Feature: search across saved items (library tab)
54. Trust: the options page showing privacy controls and site access
65. Platform: works in light and dark mode

Execution context: a planning document. Each screenshot should answer one question a potential user has, in the order they ask it: what does it do, how does it look in use, can I control it, will it fit my setup. The first image matters most — many users see only that one in search results.

2. Show the extension in context, honestly

Screenshots should show the extension’s real UI at its real size against a realistic page, with any captions accurate to the current version. Showing features that do not exist, results the extension cannot produce, or a popup at an impossible size is misleading content and a common rejection reason. Mock data inside your own UI is fine; fabricated outcomes are not.

3. Capture automatically from the real build

 1// scripts/screenshots.mjs
 2import { chromium } from "playwright";
 3const ctx = await chromium.launchPersistentContext("", {
 4  headless: false,
 5  deviceScaleFactor: 2,
 6  viewport: { width: 1280, height: 800 },
 7  args: [`--disable-extensions-except=dist/chrome`, `--load-extension=dist/chrome`],
 8});
 9const [sw] = ctx.serviceWorkers().length ? ctx.serviceWorkers() : [await ctx.waitForEvent("serviceworker")];
10const id = new URL(sw.url()).host;
11await sw.evaluate(() => chrome.storage.local.set({ items: DEMO_ITEMS }));      // seeded demo data
12const page = await ctx.newPage();
13await page.goto("http://localhost:4173/fixtures/article.html");
14const popup = await ctx.newPage();
15await popup.setViewportSize({ width: 380, height: 520 });
16await popup.goto(`chrome-extension://${id}/popup.html`);
17await popup.screenshot({ path: "shots/popup.png" });

Execution context: Node with Playwright and a Chromium build that can load extensions. Opening the popup’s HTML in a tab at the popup’s size captures it faithfully, since the toolbar popup itself cannot be screenshotted by automation. Seeding storage with demo data and using local fixture pages makes captures repeatable. Capturing at device scale factor 2 gives crisp downscaled images. See visual regression testing for extension UI.

4. Composite captures onto branded frames

 1import sharp from "sharp";
 2await sharp({ create: { width: 2560, height: 1600, channels: 4, background: "#f8fafc" } })
 3  .composite([
 4    { input: "shots/page.png", top: 160, left: 120 },
 5    { input: "shots/popup.png", top: 220, left: 1800 },
 6    { input: await renderCaption("Summarise any article in one click"), top: 40, left: 120 },
 7  ])
 8  .resize(1280, 800)
 9  .png()
10  .toFile("store/screenshot-1.png");

Execution context: Node at release time. Composing a page capture with the popup placed where it appears in the browser, plus a short caption, communicates more than a raw capture. Render at 2× and downscale for sharp text. Keep captions short (five to eight words) and readable at thumbnail size.

5. Avoid trademark and content problems

Screenshots that feature other companies’ sites, logos or content can raise trademark and copyright issues, and can imply an endorsement that does not exist. Prefer your own fixture pages styled like a typical site, or clearly generic content. Never show real users’ data. Do not use browser vendors’ logos in promotional images beyond what their brand guidelines allow.

6. Localise images for major markets

Store listings can have per-locale screenshots. Captions are the main thing to translate; if your UI is localised, capture it in each language with the same script by switching the browser locale (--lang=de). Localised images noticeably improve conversion in non-English markets.

7. Regenerate every release

Outdated screenshots are a form of misleading content and a support burden — users look for buttons that moved. Running the capture pipeline in CI on release tags keeps images current at no extra effort.

Common mistakes

• One screenshot of the settings page. Show the core action in context.
• Images of features that don’t exist yet. Misleading content.
• Third-party brands front and centre. Trademark and endorsement problems.
• Real personal data in captures. Privacy problem and potential policy violation.
• Stale screenshots. Users and reviewers notice.

Cross-browser variation

• Chrome / Edge: Chrome Web Store sizes as listed; Edge Add-ons sizes in Partner Center are similar — reuse the set.
• Firefox: AMO accepts flexible sizes; Firefox-specific UI (sidebar instead of side panel) should be captured from a Firefox build.
• Safari: App Store Connect sizes for the containing app; screenshots should show the extension in Safari on the target platform.

Verification

1. Check each image’s pixel size against the store’s requirements before upload.
2. Preview the listing at thumbnail size and confirm captions are readable.
3. Compare each screenshot with the current build and confirm every visible feature exists.
4. Confirm no real personal data or unlicensed third-party content appears.

FAQ

Can I use a mockup of the browser window?

Yes, as long as the extension UI inside it is real. A clean, accurate frame helps users understand where the UI appears.

Do promotional tiles need text?

Short brand text works; avoid dense copy — tiles are displayed small.

Is a video worth it?

For extensions with an interaction that is hard to show in stills — a keyboard workflow, a page transformation — a short video helps.

How many screenshots should I upload?

Use all the slots the store allows if each shows something distinct. Five focused images — core action, two key features, controls, theming — outperform one image repeated with different captions.

Should I keep a record of review correspondence?

Yes. Save each rejection reason and your response alongside the release log. Patterns across rejections show where your listing, permissions or features drift from what the store expects, and the history helps when an appeal cites a previous decision.

Related

• Icon sizes for the manifest and action — icons inside the package.
• Translating manifest fields and store listings — localised listings.
• Passing Chrome Web Store review — the wider review checklist.
• Store submission and permissions compliance — the parent topic.