Manifest V2 vs. V3: Was sich für Browser-Erweiterungen ändert

Manifest V3 ist die aktuelle Fassung der Erweiterungsplattform in Chromium-Browsern. Die drei wichtigsten Änderungen gegenüber V2: Der Hintergrund läuft als Service Worker statt als dauerhafte Seite, Code darf nicht mehr aus dem Netz nachgeladen werden, und Netzwerkanfragen werden über deklarative Regeln statt über blockierende Listener gefiltert. In Chrome laufen nur noch V3-Erweiterungen.

Warum es Manifest V3 gibt

Google begründet den Wechsel mit Sicherheit, Datenschutz und Leistung. Unter V2 konnte eine Erweiterung Code von einem Server laden und ausführen, der bei der Prüfung im Store noch gar nicht existierte. Eine Hintergrundseite lief dauerhaft und belegte Speicher, auch wenn die Erweiterung nichts tat. Und das blockierende webRequest gab Erweiterungen Einblick in jede Anfrage des Browsers. V3 schränkt alle drei Punkte ein.

Kritiker, vor allem aus dem Umfeld von Inhaltsblockern und Datenschutz-Werkzeugen, sehen in den Änderungen vor allem eine Schwächung von Werbeblockern. Beide Sichtweisen haben ihre Berechtigung: Die neuen Regeln schließen echte Missbrauchswege, nehmen aber auch legitimen Erweiterungen Möglichkeiten.

Die Unterschiede im Überblick

Service Worker statt Hintergrundseite

Die folgenreichste Änderung im Alltag. Ein Service Worker hat kein DOM, kein window und kein localStorage. Er startet, wenn ein Ereignis eintrifft, und wird nach kurzer Inaktivität wieder beendet. Für die Migration bedeutet das:

• Zustand auslagern: Globale Variablen sind flüchtig. Speichern Sie alles Wichtige in chrome.storage.local oder chrome.storage.session.
• Listener sofort registrieren: Ereignis-Listener müssen beim Start synchron auf oberster Ebene angemeldet werden, sonst verpasst der neu gestartete Worker das Ereignis, das ihn geweckt hat.
• Timer ersetzen: setTimeout und setInterval überleben das Beenden nicht. Für wiederkehrende Aufgaben gibt es chrome.alarms.
• DOM-Arbeit verlagern: Was ein DOM braucht, etwa HTML parsen oder Audio abspielen, erledigt ein Offscreen-Dokument über chrome.offscreen.

Firefox geht hier einen eigenen Weg: Unter Manifest V3 nutzt es eine Ereignisseite über background.scripts, die ein DOM hat. Wer für beide Browser baut, gibt im Manifest oft beide Varianten an oder erzeugt per Build-Skript getrennte Manifeste.

declarativeNetRequest statt blockierendem webRequest

Unter V2 konnte eine Erweiterung jede Anfrage abfangen, per JavaScript prüfen und blockieren oder umleiten. Unter V3 beschreibt die Erweiterung stattdessen Regeln, die der Browser selbst anwendet. Die Erweiterung sieht die einzelnen Anfragen dabei nicht.

{
  "id": 1,
  "priority": 1,
  "action": { "type": "block" },
  "condition": {
    "urlFilter": "||tracker.example^",
    "resourceTypes": ["script", "image", "xmlhttprequest"]
  }
}

Regeln können statisch im Paket liegen oder zur Laufzeit dynamisch hinzugefügt werden. Die Anzahl der Regeln ist begrenzt, und komplexe Logik, die vom Inhalt einer Anfrage abhängt, lässt sich nicht abbilden. webRequest existiert weiter, aber in Chrome nur zum Beobachten. Das blockierende Filtern ist dort auf Erweiterungen beschränkt, die per Unternehmensrichtlinie installiert werden.

Was das für Datenschutz-Erweiterungen bedeutet und wie Sie geeignete auswählen, beschreibt der Beitrag Datenschutz im Browser: Welche Erweiterungen wirklich helfen.

Kein nachgeladener Code mehr

Unter V3 muss jede ausführbare Logik im eingereichten Paket stecken. Verboten sind unter anderem:

• <script src="https://…"> in Popup oder Optionsseite,
• eval(), new Function() und vergleichbare Konstrukte in Erweiterungsseiten,
• das Herunterladen von JavaScript, um es per executeScript auszuführen.

Erlaubt bleibt das Abrufen von Daten, also Konfigurationen, Listen oder Texte im JSON-Format. Wer bisher eine Bibliothek per CDN eingebunden hat, legt sie künftig ins Paket. Für Sonderfälle, in denen dynamischer Code nötig ist, gibt es sandboxed Seiten ohne Zugriff auf die Erweiterungs-APIs.

Host-Berechtigungen und Nutzerkontrolle

Unter V2 standen API-Rechte und Websitezugriffe gemeinsam im Feld permissions. V3 trennt beides: API-Rechte wie storage oder tabs bleiben in permissions, Adressmuster wie https://*.example.com/* wandern nach host_permissions. Das wirkt wie eine Formalie, hat aber praktische Folgen. Browser können Websitezugriffe getrennt anzeigen und Nutzern erlauben, sie einzuschränken, ohne die Erweiterung zu entfernen. In Chromium-Browsern lässt sich der Zugriff etwa auf „Bei Klick“ stellen.

Für Entwickler heißt das: Eine Erweiterung darf sich nicht darauf verlassen, dass ein im Manifest angeforderter Websitezugriff tatsächlich gewährt ist. Prüfen Sie vor dem Zugriff mit chrome.permissions.contains, ob das Recht vorliegt, und fordern Sie es bei Bedarf mit chrome.permissions.request an. Diese Anfrage muss aus einer Nutzeraktion heraus erfolgen, etwa einem Klick im Popup. Wer Rechte von Anfang an als optional plant und erst bei Bedarf abfragt, erzeugt bei der Installation weniger Warnhinweise und hat es bei der Store-Prüfung leichter. Die Berechtigung activeTab ist für viele Fälle der eleganteste Weg, weil sie gar keinen Hinweis auslöst und trotzdem Zugriff auf den aktuellen Tab gibt, sobald jemand die Erweiterung aufruft.

Der Zeitplan in Chrome

Chrome hat Manifest V2 in mehreren Stufen beendet. Zunächst wurden V2-Erweiterungen in Vorabversionen und dann in der stabilen Version mit Warnhinweisen versehen und deaktiviert, wobei Nutzer sie anfangs wieder einschalten konnten. Seit Mitte 2025 lassen sie sich für normale Nutzer nicht mehr einschalten. Unternehmen konnten sie per Richtlinie nur noch für eine kurze Übergangszeit weiter betreiben, die mit Chrome 138 endete. Für Entwickler heißt das: Eine V2-Erweiterung lässt sich in Chrome weder installieren noch aktualisieren.

Firefox und Safari

Firefox unterstützt Manifest V3 seit Anfang 2023 und hat angekündigt, Manifest V2 vorerst nicht abzuschalten. Unter V3 weicht Firefox in zwei wichtigen Punkten von Chrome ab: Der Hintergrund läuft als Ereignisseite, und blockierendes webRequest bleibt erlaubt. Zudem behandelt Firefox Websitezugriffe unter V3 als Rechte, die Nutzer gezielt erteilen oder entziehen können. Wie Sie ein Firefox-Add-on aufsetzen und einreichen, zeigt Firefox-Add-on erstellen.

Safari unterstützt Manifest V3 einschließlich declarativeNetRequest. Als Hintergrund akzeptiert Safari einen Service Worker oder eine nicht persistente Seite.

Migration: die Checkliste

1. manifest_version auf 3 setzen.
2. browser_action und page_action durch action ersetzen, im Code chrome.browserAction durch chrome.action.
3. Adressmuster aus permissions nach host_permissions verschieben. Prüfen, ob activeTab ausreicht.
4. Hintergrundseite in einen Service Worker umbauen: Zustand nach chrome.storage, Timer nach chrome.alarms, DOM-Zugriffe in ein Offscreen-Dokument.
5. tabs.executeScript und tabs.insertCSS durch scripting.executeScript und scripting.insertCSS ersetzen.
6. Blockierendes webRequest in declarativeNetRequest-Regeln übersetzen.
7. Externe Skripte und eval entfernen, Bibliotheken ins Paket legen.
8. content_security_policy und web_accessible_resources ins neue Format bringen.
9. Gründlich testen, insbesondere das Verhalten nach dem Beenden und Neustarten des Service Workers.

Ein praktischer Test: Beenden Sie den Service Worker in chrome://serviceworker-internals oder über die Erweiterungsseite und lösen Sie dann eine Funktion aus. Wenn sie danach noch funktioniert, ist der Zustand richtig ausgelagert.

Was V3 für Nutzer bedeutet

Für die meisten Nutzer ändert sich wenig, die Erweiterungen sehen gleich aus und funktionieren gleich. Spürbar wird der Wechsel bei Inhaltsblockern, die mit festen Regellisten arbeiten müssen, und bei älteren, nicht mehr gepflegten Erweiterungen, die in Chrome einfach verschwunden sind. Positiv: Eine Erweiterung kann ihr Verhalten nach der Store-Prüfung nicht mehr durch nachgeladenen Code grundlegend ändern. Wer eine Erweiterung neu beginnt, startet mit V3, wie in der Anleitung Chrome-Erweiterung programmieren gezeigt.