Free · reusable · no checkout
Indie Extension Release Checklist
A pre-submission pass for Manifest V3 extensions built around the mistakes that are expensive to discover after packaging: wrong ZIP structure, overbroad permissions, mismatched privacy copy, weak listing media, untested upgrade paths, and missing release evidence.
1. Package the release, not the project folder
- Confirm manifest_version is 3.
- Increment the extension version before packaging.
- Put manifest.json at the ZIP root, not inside an extra parent folder.
- Remove source maps, private notes, credentials, test exports, and unrelated build artifacts.
- Install the exact packaged build in a clean Chrome profile before submission.
2. Review permissions like a reviewer will
- Keep permissions and host permissions to the minimum the shipped feature needs.
- Remove permissions left over from experiments or deleted features.
- Write a one-sentence reason for every sensitive permission.
- Confirm the listing copy and privacy disclosures describe the same data access as the manifest.
3. Make privacy claims match the product
- Use a public privacy-policy URL that loads without authentication.
- State what the extension stores locally, what leaves the device, and why.
- If licensing sends a license key or instance identifier to a provider, disclose that path accurately.
- Do not claim zero data transfer if activation, telemetry, sync, or third-party APIs transmit anything.
4. Prepare the Chrome Web Store media
- Use a clear 128×128 extension icon.
- Prepare 1280×800 or 640×400 screenshots with real UI and readable feature callouts.
- Keep screenshots focused on one feature or outcome at a time.
- Do not fake browser chrome, ratings, reviews, user counts, or unsupported functionality.
- Check every screenshot at the size it will actually appear in the store.
5. Run clean-profile QA
- Install from the packaged ZIP with no prior extension storage.
- Test first-run behavior, core actions, settings, and error states.
- Test upgrade behavior from the currently published version when possible.
- Test the permanent Free state and every license-gated path without changing entitlements.
- Test uninstall/reinstall expectations and verify local backups or exports where the product promises them.
6. Prepare reviewer notes
- Explain any feature that is not obvious from the first screen.
- Give precise steps for reaching functionality that requires setup.
- Explain why sensitive permissions are needed.
- If a paid feature exists, explain how a reviewer can evaluate the extension without exposing secrets.
7. Capture release evidence
- Record the final version number and source commit.
- Keep the source ZIP and publish-ready ZIP separately labeled.
- Save screenshots of the exact listing copy and media submitted.
- Record privacy-policy URL, licensing provider reference, Free/Trial/Pro rules, and migration behavior.
- After publication, verify the live Web Store page instead of assuming approval means the listing rendered correctly.
Keep a local copy
Use the Markdown version inside your repo.
Drop it into release documentation, customize it for the extension, and check off the same list against the exact ZIP you plan to publish.