> ## Documentation Index
> Fetch the complete documentation index at: https://docs.extensy.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Manifest V3

> Understand why Chrome moved to Manifest V3 and how Extensy handles MV3 complexity automatically.

Manifest V3 (MV3) is the current, required standard for building and publishing Chrome extensions. If you've browsed extension tutorials recently, you've likely seen it mentioned — and with good reason. Google now requires MV3 for all new Chrome Web Store submissions.

Extensy generates MV3 extensions by default, so you never have to deal with the architectural details manually.

## Why Google introduced MV3

Chrome introduced MV3 to make extensions safer, more private, and less resource-intensive for users.

> **Security**
>
> MV3 prevents remote code execution. Every line of code your extension runs must be bundled inside the submitted ZIP file — no downloading scripts at runtime.

> **Privacy**
>
> MV3 introduces more granular permissions, giving users clearer control over which sites an extension can access.

> **Performance**
>
> MV3 replaces persistent background pages with event-driven service workers that only run when needed, saving battery and memory.

> **CWS requirement**
>
> Google has deprecated MV2 and requires MV3 for all new submissions and renewals on the Chrome Web Store.

## MV2 vs. MV3: key differences

| Feature | Manifest V2 (legacy) | Manifest V3 (current) |
| :- | :- | :- |
| **Background script** | Persistent background page | Event-driven service worker |
| **Network interception** | `webRequest` (blocking) | `declarativeNetRequest` (static rules) |
| **Code injection** | Remote scripts allowed | Bundled local scripts only |
| **Toolbar actions** | Separate `browser_action` / `page_action` | Unified `action` API |
| **CWS status** | Deprecated | Required |

## How Extensy handles MV3 for you

Building MV3 extensions manually is tricky — service worker lifetimes are short, the `declarativeNetRequest` API requires static rule files, and older patterns like `eval()` are outright banned.

Extensy takes care of all of this automatically:

**1. Automatic service workers**

Extensy generates a correctly structured `background.js` service worker, including the event listeners Chrome expects.

**2. Minimum-privilege permissions**

Your manifest only requests the permissions that match your prompt — nothing more.

**3. Modern action API**

Extensy always uses the unified `action` key instead of the deprecated `browser_action` or `page_action` keys.

**4. No remote code**

All generated code is bundled locally at build time, keeping your extension fully compliant with MV3 security rules.

## Watch out for outdated tutorials

StackOverflow and older blog posts are full of MV2 examples. The two clearest warning signs are:

* A `background.html` file referenced in the manifest
* `webRequest` used to block or redirect URLs

> [!TIP]
>
> If a tutorial references `chrome.extension.getBackgroundPage()` or sets `"manifest_version": 2`, it is using an outdated MV2 pattern. Extensy's generated code always uses the correct MV3 equivalents.

> [!WARNING]
>
> MV3 prohibits `eval()` and runtime code-string injection. If you manually add these patterns to an Extensy extension, the Chrome Web Store will reject your submission.

> [!NOTE]
>
> You never need to configure MV3 settings manually when using Extensy. The service worker lifecycle, declarative rules, and permission scoping are all handled for you behind the scenes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.