Chrome Extensions After Manifest V3: What Actually Changed (And What Didn't)

TL;DR

Manifest V2 is officially dead. Chrome now requires all extensions to use Manifest V3. Despite years of panic, ad blockers work fine, privacy extensions adapted, and locally-processing tools like Convert: Web to PDF were MV3-ready from the start. Here is what actually changed, what the myths got wrong, and what to look for in extensions going forward.

The timeline of Manifest V3

For anyone who missed the multi-year saga, here is what happened:

• 2018 — Google announces plans for Manifest V3, a new set of rules for Chrome extensions.
• 2020 — First MV3 developer previews. Immediate backlash from ad blocker developers over changes to the webRequest API.
• 2021-2023 — Google iterates on MV3, increasing the limit on declarativeNetRequest rules (a key concern for ad blockers).
• 2024 — MV2 deprecation begins. Extensions must migrate to MV3 to remain in the Chrome Web Store.
• 2025 — MV2 extensions stop working in Chrome stable. Stragglers get removed from the store.
• 2026 — MV3 is the only option. The transition is complete.

What Manifest V3 actually changed

Service workers replace background pages

What changed: MV2 extensions could run persistent background pages — scripts that stayed alive as long as Chrome was running. MV3 replaces these with service workers that spin up on demand and shut down after a period of inactivity.

What this means for users: Extensions that needed to maintain persistent connections (some messaging apps, certain monitoring tools) had to redesign how they work. For most extensions, you will not notice any difference.

What it does not mean: Extensions are not less capable. They can still do the same work — they just do it in response to events rather than running constantly in the background. This actually reduces memory usage.

declarativeNetRequest replaces webRequest (for blocking)

What changed: MV2 allowed extensions to intercept and modify every network request in real-time using the webRequest API. MV3 replaces the blocking version of this with declarativeNetRequest, where extensions provide rules in advance and Chrome applies them.

What this means for users: Ad blockers had to convert their filter rules to the declarativeNetRequest format. Google progressively increased the rule limit from an initial 5,000 to much higher numbers, accommodating the needs of comprehensive blockers.

What it does not mean: Ad blockers are not broken. uBlock Origin Lite, AdBlock Plus, and other major ad blockers work under MV3. The filtering is different under the hood, but the user experience is largely the same.

Tighter permission controls

What changed: MV3 enforces more granular permissions. Extensions must declare exactly what they need, and users have more control over granting access (e.g., allowing an extension to work on specific sites rather than all sites).

What this means for users: You see more specific permission requests when installing extensions. You can grant an extension access to only the sites where you actually use it.

What it does not mean: This is not a limitation — it is an improvement. Users have more control, and extensions that request minimal permissions are easier to trust.

Content Security Policy restrictions

What changed: MV3 prevents extensions from executing remotely-hosted code. All code must be bundled with the extension at the time of review. Extensions cannot load and run scripts from external servers.

What this means for users: This is a major security win. In MV2, a malicious extension update could make an extension load harmful code from an external server after passing review. MV3 makes this impossible.

What it does not mean: Extensions are not frozen in time. They still receive updates through the Chrome Web Store — those updates just have to pass review with all code included.

Myth-busting: what the panic got wrong

Myth: Ad blockers are dead

Reality: Ad blockers adapted. The declarativeNetRequest API works differently than webRequest, but it blocks ads effectively. uBlock Origin Lite and other MV3-compatible blockers have been working reliably since 2024. If your ad blocker is not working, you probably need to update it — not because MV3 broke ad blocking.

Myth: Privacy extensions cannot function under MV3

Reality: Privacy extensions like Privacy Badger, HTTPS Everywhere (now built into browsers), and anti-tracking tools all work under MV3. The declarativeNetRequest API supports the rule types needed for tracker blocking. Some extensions needed significant rewrites, but the end result for users is functionally equivalent.

Myth: Google made MV3 to protect its ad revenue

Reality: This was the most persistent narrative, and it was mostly wrong. Google makes money from ads, so it had a conflict of interest. But the MV3 changes genuinely improve security and performance for users. The increased rule limits in declarativeNetRequest show Google responded to ad blocker concerns rather than trying to kill them.

The real story is more nuanced: Google wanted to reduce the security risks of extensions having unlimited access to network requests (a legitimate concern) while maintaining extension functionality (which required years of iteration).

Myth: All your favorite extensions stopped working

Reality: The vast majority of popular extensions migrated to MV3 well before the final deadline. Extension developers had years of lead time. Extensions that did not migrate were typically abandoned or unmaintained — they probably had other problems too.

What MV3 means for privacy-first extensions

Extensions that process data locally were the easiest to migrate to MV3, and they benefit the most from the new framework. Here is why:

Fewer permissions needed

An extension that processes data locally does not need broad network access. Convert: Web to PDF does not need to intercept network requests, modify web traffic, or communicate with external servers. Its permission footprint under MV3 is minimal because it was already doing things the MV3 way.

No remote code execution concerns

MV3's ban on remote code execution is irrelevant to extensions that never loaded remote code in the first place. Locally-processing extensions bundle all their functionality in the extension package. There is nothing to change.

Service workers are a natural fit

For extensions triggered by user action (click the icon, convert the page), service workers are ideal. The extension does not need to run in the background waiting for something to happen. It activates when you click, does its job, and goes back to sleep. This is exactly how MV3 service workers are designed to work.

Transparent permission model

Under MV3's granular permissions, users can see exactly what a locally-processing extension accesses. An extension like Convert: Web to PDF needs access to the active tab (to read the page content for conversion) and not much else. This transparency builds trust because there is nothing hidden.

How to evaluate extensions in the MV3 era

Now that MV3 is the standard, here is how to evaluate whether an extension is trustworthy:

Check the permissions

Go to the extension's Chrome Web Store listing or chrome://extensions page. Look at what permissions it requests:

• "Read and change all your data on all websites" — This is the broadest permission. Some extensions genuinely need it (ad blockers must inspect every page). Others request it out of laziness. Be cautious.
• "Read and change your data on specific sites" — Better. The extension only works on certain domains.
• "Read your data on the active tab" — Minimal. The extension can only see the page you are currently viewing, and only when you invoke it. This is the ideal permission level for tools you trigger manually.

Check the data practices

The Chrome Web Store now requires extensions to disclose their data practices. Look for:

• Does it collect data? — A locally-processing extension should collect nothing.
• Does it transmit data to servers? — PDF creation should not require server communication.
• Does it share data with third parties? — There should be no third parties involved in local processing.

Check the code visibility

MV3 extensions cannot load remote code, so everything the extension does is in the package. While you cannot easily read the code yourself (unless the extension is open source), security researchers can — and do — audit popular extensions.

Check the update frequency

Regular updates suggest active maintenance and security patching. An extension that has not been updated in two years may have unpatched vulnerabilities or compatibility issues.

Extensions that actually benefit from MV3

Several categories of extensions are objectively better under MV3:

Productivity tools

Extensions that activate on demand (PDF converters, screenshot tools, note-taking clippers) fit the service worker model perfectly. They use less memory when idle and respond immediately when invoked.

Developer tools

DevTools extensions and debugging tools benefit from the stricter permission model. They access specific APIs and do not need broad page access.

Privacy and security tools

Extensions focused on user privacy benefit from the reduced permission surface. When you install a privacy extension under MV3, the permission dialog tells you exactly what it can access, and the answer is usually much more limited than MV2 allowed.

Content creation tools

Tools that help you create content (write, format, convert) rather than monitor or modify web traffic are natural fits for MV3. Convert: Web to PDF falls into this category — it creates a PDF from the page you are viewing, using only the permissions needed for that specific action.

What to do with your extension list

Now that MV3 is fully enforced, take a few minutes to audit your installed extensions:

1. Go to chrome://extensions — See everything you have installed.
2. Remove what you do not use — Every extension is potential attack surface, even well-built ones. If you have not used it in six months, remove it.
3. Check for replacements — If an extension you liked did not migrate to MV3, look for MV3 alternatives that do the same job.
4. Review permissions — Click "Details" on each extension and check what permissions it has. Remove or restrict any that seem excessive.
5. Enable "site access" controls — For extensions that do not need to run on every page, use Chrome's site access settings to limit where they can operate.

The cross-browser picture

MV3 is not Chrome-only anymore:

• Firefox — Supports MV3 with some differences (Firefox's implementation is slightly more extension-friendly in some areas).
• Edge — Uses Chromium, so MV3 works identically to Chrome.
• Brave — Also Chromium-based, full MV3 support.
• Safari — Has its own extension framework, but the principles are similar.

Extensions built for MV3 on Chrome typically work on Edge and Brave with minimal changes. This is good for users — it means more extension choices across browsers.

Related reading

• Chrome's 4th Zero-Day of 2026: Why Extension Choice Matters for Security — how recent browser vulnerabilities make extension architecture matter more
• PDF Converter: Chrome Extension vs Online Tools — Which Is Better? — practical example of how MV3 extensions compare to web-based tools
• How AI Is Changing the Way We Save and Organize Web Content in 2026 — the next evolution for browser extensions beyond MV3

Frequently asked questions

Do I need to do anything as a user?

No. If your extensions are still working, they have already migrated to MV3. If an extension stopped working, it was probably removed from the store because it did not migrate. Search for an MV3 alternative.

Are MV3 extensions slower than MV2?

In most cases, no. Service workers add a small startup delay (milliseconds) compared to persistent background pages, but this is imperceptible for user-triggered extensions. For extensions that process data on click (like PDF converters), there is no noticeable difference.

Can I still install extensions from outside the Chrome Web Store?

Developer mode still allows loading unpacked extensions, but this is intended for development, not everyday use. Side-loaded extensions do not go through Chrome Web Store review and may pose security risks.

Is uBlock Origin gone?

The original uBlock Origin (MV2) is no longer supported in Chrome. uBlock Origin Lite (MV3) is the replacement for Chrome users. If you use Firefox, the original uBlock Origin still works because Firefox continues to support certain MV2 APIs alongside MV3.

Did any extensions get worse under MV3?

Some niche extensions that relied on real-time network request modification (certain debugging tools, very specialized ad blockers) lost some granularity. For the vast majority of users and use cases, the difference is negligible or invisible.

How does this affect Convert: Web to PDF?

Convert: Web to PDF was designed with a local-first architecture that aligns with MV3 principles. It processes everything in your browser, requests minimal permissions, and activates only when you click the icon. The MV3 transition had no negative impact on its functionality.

Bottom line

Manifest V3 is here, MV2 is gone, and the sky did not fall. Ad blockers work. Privacy extensions adapted. The extensions that benefit most from MV3 are the ones that were already doing things right — processing locally, requesting minimal permissions, and activating on demand. When choosing extensions in 2026, look for small permission footprints, local processing, and active maintenance. Convert: Web to PDF checks all three boxes, and it works exactly the same as it did before the transition.