Manifest V3 Pre-Submission Checklist for Chrome Web Store

Check the artifact Chrome Web Store will actually receive

A source tree can look correct while the release ZIP is still wrong. Common mistakes include zipping the parent folder, shipping old build output, leaving a referenced page out of dist, or bundling a dependency that creates remote script loaders. The submission checklist should be run against the same ZIP you intend to upload, not against a development directory.

• •Confirm manifest.json is at ZIP root.
• •Confirm every manifest-declared page, icon, script, and ruleset exists in the package.
• •Confirm production build output does not reintroduce remote executable code.

Make the checklist repeatable for every release

Treat the scan report as a release gate. Before each Chrome Web Store upload, rebuild the extension, scan the ZIP, review scan-limit notes, then save the Markdown or JSON report with the release notes. This does not prove approval, but it makes packaging and policy-risk review consistent across versions.

• •Run the same checklist after dependency upgrades.
• •Review Medium permission reminders even when no High findings appear.
• •Keep manual Dashboard privacy checks outside the scanner report.

Package structure checks should happen before policy wording

A clean privacy explanation cannot compensate for a broken release ZIP. Before editing listing copy, confirm that the root manifest exists, referenced files are present, icons resolve, background service worker paths are local, and content script files exist where the manifest says they do. These checks are mechanical, but they prevent avoidable upload failures and confusing rejection loops.

• •Open the ZIP root and verify manifest.json is not inside a nested build folder.
• •Check every manifest-declared executable file against the packaged file list.
• •Confirm the version number is ready for a new upload when code or packaged assets changed.

Use the checklist as a release gate, not a one-time audit

The best use of a pre-submission checklist is repeatability. Run it whenever dependencies, bundler settings, analytics, authentication, permissions, or dashboard privacy answers change. A release that passed once can fail later if a package update introduces a remote loader, dynamic worker, broader host pattern, or new API permission.

• •Scan after production build output is finalized.
• •Keep a short record of High findings fixed and Medium findings reviewed.
• •Re-run the scan after removing files, because manifest references can become stale.

What still belongs in manual review

Some submission risks cannot be decided from ZIP text alone. Dashboard privacy fields, single-purpose fit, reviewer interpretation, user-facing disclosure, and whether a permission is justified by the product experience still need a human check. Keep those items in the checklist, but do not label them as automatic code violations unless the package itself contains a direct signal.

• •Map each permission to one visible feature.
• •Confirm privacy fields describe the same behavior as the extension UI.
• •Use official dashboard and policy pages as the final wording reference.

Why does ZIP root packaging matter?

Chrome Web Store evaluates the submitted package. If manifest.json is nested inside a folder instead of at the ZIP root, the package can fail before deeper review.

Can the scanner validate every Chrome policy?

No. It checks static package signals. You still need to review listing metadata, privacy practices, and actual extension behavior.

Should I rerun the scanner after each fix?

Yes. Rebuild the production ZIP after changes and scan the rebuilt package, because bundler output can change paths and generated files.