manifest_version
The manifest_version field tells Chrome which extension platform rules to apply. New Chrome extensions should use manifest_version 3, and this validator treats any other value as a blocking migration issue.
Chrome Extension Review Prep
Chrome Extension Manifest V3 Validator
Paste a manifest.json and get a browser-only audit for MV3 schema issues, risky permissions, migration leftovers, service worker setup, CSP, content scripts, and Chrome Web Store readiness.
Input
Paste or upload manifest.json
Drop manifest.json here
Overall score --
Findings
Permission audit
Chrome Web Store readiness
Manifest preview
Why we built this
Chrome extension teams are still cleaning up the operational edge cases of Manifest V3. The migration deadline pushed most new development onto MV3, but many production manifests still carry MV2 habits from old boilerplates, blog tutorials, and rushed store updates. A validator does not replace the Chrome documentation, but it gives teams a quick preflight before they package a zip, wait for review, or debug a rejection that started as a simple manifest mismatch.
The bugs are usually small and expensive: webRequestBlocking stays in permissions after a move to declarativeNetRequest, browser_action survives instead of action, web_accessible_resources remains a flat array, or content_security_policy is left as an MV2 string. Each issue can turn a working local build into a failed review or a broken packaged extension. The common thread is that MV3 is stricter about background execution, exposed resources, and packaged code, so legacy keys can fail even when the feature still looks correct in a developer profile.
Permission minimization matters for more than security optics. Reviewers need to see a clean match between the feature users see and the APIs the extension requests. Replacing <all_urls> with narrower host permissions, documenting storage or identity usage, and removing unused sensitive permissions can make review faster and reduce scary install prompts. It also gives users a better first impression: a focused extension with narrow access feels intentional, while a broad permission list makes even useful software look risky.
This validator is the focused sibling to Extension Auditor. Use Extension Auditor to inspect an installed extension from the outside, then use this tool before submission to catch manifest-level MV3, permission, CSP, and store-readiness problems in the file you are about to ship.
Manifest V3 mini-glossary
service_worker
MV3 replaces persistent background pages with an event-driven background service worker. The path lives under background.service_worker and should point to a packaged extension file, not a remote script.
host_permissions
Host permissions declare which websites an extension can read or change. Narrow patterns such as https://example.com/* are easier to justify than <all_urls> because they match a clearer user-facing feature.
declarativeNetRequest
declarativeNetRequest is the MV3 API for request blocking and modification. It replaces most webRequestBlocking use cases with static or dynamic rules that Chrome can evaluate without long-running background code.
web_accessible_resources
MV3 web_accessible_resources entries are objects with resources and matches arrays. A flat file list is an MV2 leftover and can break content-script assets after migration.
content_security_policy
MV3 expects content_security_policy to be an object with extension_pages and optional sandbox keys. Unsafe tokens such as unsafe-eval and unsafe-inline usually point to bundled-code problems that reviewers will question.
action vs browser_action
MV2 split toolbar behavior between browser_action and page_action. MV3 uses action, so old keys should be renamed and simplified during migration.
_locales/messages.json
When default_locale is present, Chrome expects localized strings under _locales/<language>/messages.json. A manifest-only validator cannot inspect your zip, so treat this as a packaging checklist item.