Preparing a Chrome extension for the Web Store often means opening an image editor, resizing the same logo several times, exporting promotional tiles, and then copying paths into manifest.json. The work is repetitive, but the mistakes are expensive: a missing icon, a distorted square, or a stale asset can delay a submission.
This tutorial uses Chrome Web Store Assets Generator, an MIT-licensed React and TypeScript project, to build that asset workflow locally. You will run the app, generate icon and promotional-image variants from one logo, copy a Manifest V3 icon block, and download the result as a ZIP file. The image processing happens in the browser with the Canvas API, so the logo does not need to be uploaded to an application server.
What you will build
The project generates seven files from one uploaded image:
- 16x16, 32x32, 48x48, and 128x128 extension icons
- 440x280, 920x680, and 1400x560 promotional tiles
- an organised ZIP containing
icons/andbanners/
The generated icon sizes line up with Chrome's documented extension icon uses. Chrome documents 16x16, 32x32, 48x48, and 128x128 icon variants, and recommends PNG for best visual results. The Chrome icon guidance also explains why square source artwork matters.
The promotional sizes come from the project's current source and README. Chrome's promotional image documentation documents the 440x280 small tile and 1400x560 marquee tile. The application also produces a 920x680 large tile. Screenshots are a separate Web Store requirement and are not generated by this tool.
Prerequisites
You need:
- Node.js 18 or newer
- npm
- a PNG, SVG, JPG, or WebP logo
- a browser with Canvas and download support
For the best result, start with a square logo at least 512x512 pixels. This is a recommendation from the project's documentation, not a hard validation rule enforced by the app.
Run the app from source
Clone the repository and install its locked dependencies:
git clone https://github.com/paladini/chrome-web-store-assets-generator.git
cd chrome-web-store-assets-generator
npm install
Start Vite's development server:
npm run dev
Open http://localhost:3000. The repository's current package.json defines the development command with Vite on port 3000. If that port is already in use, Vite may choose another port and print it in the terminal.
You can also use the project's Docker image without a source checkout:
docker run -d -p 3000:80 --name assets-generator paladini/chrome-web-store-assets-generator:latest
The Docker command is convenient for trying the published image. Use the source workflow when you want to inspect or modify the implementation.
Generate the icon set and banners
- Drop your logo onto the upload area, or use the file picker.
- Set the extension name and subtitle used in promotional banners.
- Adjust icon padding while watching the previews update.
- Switch between the Icons, Banners, and Store Preview tabs.
- Select Download All (.zip).
The current implementation creates the icon and banner data URLs in the browser. Its image utility draws the source image onto a Canvas at each target size, applies the selected padding, and converts the result for download. The ZIP action uses JSZip to place the generated files under separate icons/ and banners/ directories.
The tool also shows a Manifest V3 snippet. A minimal version of the generated structure looks like this:
{"manifest_version":3,"name":"Example Extension","version":"1.0.0","icons":{"16":"icons/16x16.png","32":"icons/32x32.png","48":"icons/48x48.png","128":"icons/128x128.png"}}The exact filenames should come from the downloaded archive and the snippet shown by the running version. Chrome's Manifest V3 reference requires manifest_version to be 3 for current extensions and documents the icons key.
Verify the project before using it
This repository does not currently define a test script, but it does define TypeScript checking and a production build. From the cloned directory, run:
npm run lint
npm run build
npm run lint runs tsc --noEmit, which checks the TypeScript project without writing compiled files. npm run build runs Vite and creates the production bundle in dist/.
To verify the browser workflow itself, use a disposable logo and check these results:
- The Icons tab shows four square icon previews.
- The Banners tab shows three promotional dimensions.
- Changing padding changes the icon composition without changing the target dimensions.
- The ZIP contains
icons/andbanners/entries. - The copied manifest paths match the files in the ZIP.
- The browser's network panel shows no application upload request while generating assets.
That last check is worth doing because "client-side" is a behavior claim. The source uses browser APIs for image processing, and the live application describes itself as serverless, but you should still inspect the deployed build or your own build when privacy matters.
Why local generation helps
The main benefit is consistency. Every output is derived from the same source image, dimensions are encoded in one asset definition, and the manifest snippet is generated alongside the files. That removes several opportunities for a manual export workflow to drift.
The second benefit is a smaller data boundary. A logo can be proprietary even when the extension is public. A local browser workflow avoids sending that image to a resizing service. This is not a security guarantee: browser extensions can still be inspected locally, third-party browser behavior can change, and the tool cannot protect an image after you export or share it.
The third benefit is reviewability. Because the project is a normal Vite application, you can inspect the image utility, the asset definitions, and the ZIP code before deploying it. You can also serve the generated dist/ directory with a static web server rather than adding a backend.
Failure modes and limitations
The source logo looks blurry
Use a larger square source image and leave enough padding for the smallest icon. A detailed illustration may look acceptable at 128 pixels but lose important features at 16 pixels. The app resizes the image; it does not recreate missing detail.
The store still asks for screenshots
That is expected. Promotional tiles and screenshots serve different purposes. Chrome's documentation requires a screenshot for a store listing, while this project explicitly does not generate screenshots. Capture the actual extension UI separately at an accepted size.
The generated banner does not fit your brand
The app offers extension name, subtitle, padding, and gradient-palette controls. It is an asset generator, not a complete design system. Review text contrast, legibility at reduced size, and Chrome's branding requirements before submitting.
The build reports dependency vulnerabilities
Check the exact audit output in your checkout instead of treating a count as a fixed project property. In the current verification checkout, npm ci reported 15 findings across low, moderate, and high severities. That is a dependency-health signal, not proof that the application is exploitable. Review the dependency tree, lockfile, and advisories before exposing a hosted build.
The download is blocked or incomplete
Browser download permissions, private browsing settings, and extensions that intercept downloads can interfere. Try the workflow in a clean browser profile and confirm that each file appears before publishing the ZIP.
FAQ
Does the tool need an API key?
No. The documented workflow runs in the browser and does not require an API key.
Does it create an extension package?
No. It creates image assets, a manifest icon snippet, and a ZIP of those assets. You still need to build, test, and package the extension itself.
Can I use it for a private extension logo?
The local source workflow is designed to keep image processing in your browser. Verify the network behavior of the exact build you run, and avoid uploading sensitive images to any hosted service unless you have approved that data flow.
Does it replace store review requirements?
No. It does not validate your extension's permissions, functionality, screenshots, privacy disclosures, or compliance with Chrome Web Store policies.
Takeaway
If your extension workflow repeatedly exports the same logo into fixed Chrome sizes, a small browser-based utility can turn that repetitive task into a reviewable, reproducible step. Chrome Web Store Assets Generator provides that step with React, TypeScript, Canvas, and JSZip while leaving screenshots and final store compliance to you.
AI assistance disclosure: AI helped organize and edit this tutorial. The repository behavior, commands, source dimensions, build checks, and linked documentation were reviewed against the current public project and primary Chrome documentation before publication.
What part of your extension publishing workflow would you most want to make reproducible: image generation, screenshot capture, manifest validation, or store submission checks?