VKT Toolkit · 12. September 2026 · 8 Min. Lesezeit

ModHeader vs. VKT Header: Welcher HTTP-Header-Modifier passt zu 2026?

Wenn Sie jemals einen Authorization-Header brauchten, um eine Staging-API zu testen, oder einen User-Agent rotieren ließen, um zu sehen, was der Server zurückgibt, sind Sie vermutlich bei ModHeader gelandet — jahrelang die Standardantwort in Chrome. Den Ruf hat er sich verdient. Aber 2026 bietet eine andere Bauform des Werkzeugs: VKT Header erledigt denselben Kernjob mit Domain-Bindung, automatischem Aufräumen und einmaligem Preis. Hier ist der Direktvergleich, den wir vor der Installation beider Tools lesen wollten.

Was Header-Modifier-Erweiterungen tatsächlich tun

Vor den Marken: die Mechanik. Jede HTTP-Anfrage trägt Header — kleine Schlüssel-Wert-Zeilen, die dem Server sagen, wer Sie sind und was Sie wollen. User-Agent nennt Ihren Browser, Referer sagt, woher Sie geklickt haben, Authorization trägt API-Keys, und eigene Header (X-*) tragen, was Ihr Backend erwartet. Ein Header-Modifier schreibt diese Zeilen beim Hinausschicken um, sodass der Server sieht, was Sie festlegen. In Manifest-V3-Browsern ist der saubere Weg dafür declarativeNetRequest-Sitzungsregeln — die gelöscht werden, wenn der Browser neu gestartet wird. Genau so ist VKT Header gebaut.

ModHeader: der etablierte Standard

ModHeader hat den Workflow „Popup öffnen und tippen“ populär gemacht: Header setzen, er gilt für die Browsersitzung — der Name ist allen ein Begriff. Die Stärken, ehrlich benannt: ausgereifter Funktionsumfang, Modi für Response-Header und Request-Filter, Team-Freigabe in den Bezahlplänen, browserübergreifende Unterstützung. Die Reibungspunkte sind vor allem ökonomischer Natur und liegen im Geltungsbereich: Der Free-Tier begrenzt Sie auf wenige Header, bevor die Profile hinter der Paywall landen, es läuft auf ein Abonnement statt auf einen Kauf hinaus, und das klassische Verhalten — Header gelten global über alle Tabs, wenn Sie keine Filterregeln bauen. Genau diese „global per Default“-Gewohnheit führt dazu, dass Test-API-Keys bei unbeteiligten Anfragen mitfahren.

VKT Header: der domaingebundene Herausforderer

VKT Header ist eine Manifest-V3-Erweiterung für Chrome und Edge, gebaut um eine Idee: Header-Regeln sollten wegwerfbar und eingegrenzt sein.

• Profile statt Rohfelder: Speichern Sie einen Header-Schnappschuss (5 kostenlose Profile mit je 5 Headern; mit Premium unbegrenzt) — „Staging-API“, „Mobiler-UA-Test“, „Kunden-Demo“ — ein Klick zum Anwenden.
• Domain-Bindung: Regeln gelten nur für die gebundenen Domains. Ihr Staging-Key kann nicht in unbeteiligte Seiten durchsickern.
• URL-Abgleich: Binden Sie Profile an bestimmte URLs, damit die richtigen Header automatisch der richtigen Seite folgen.
• Sitzungsregeln mit Auto-Cleanup: Basierend auf declarativeNetRequest-Sitzungsregeln — Browser neu gestartet, jede Regel ist verschwunden. Nichts bleibt zurück, nichts ist am nächsten Morgen still und leise aktiv.
• Import/Export (Premium): Template-Sets zwischen Rechnern verschieben, als einfache Datei mit Teamkollegen teilen.
• Local-first-Datenschutz: Kein Upload, kein Konto, keine Analyse; Berechtigungen sind nur declarativeNetRequest und storage. Sechs Oberflächensprachen, automatisch erkannt.

Premium hebt die Regel- und Header-Grenzen für $9.99 einmalig, lebenslang auf — kein Abo. Die ehrlichen Grenzen: VKT Header bearbeitet Request-Header (der häufige Entwicklerbedarf), und es ist eine kleine unabhängige Erweiterung — ModHeaders Enterprise-/Team-Infrastruktur und seine Response-Header-Werkzeuge sind tiefer.

Request-Tester: warum ein Header nicht greift

„Ich habe ihn gesetzt, der Server sieht ihn trotzdem nicht“ — dieser Satz kostet beim Header-Debugging die meiste Zeit. Bisher blieb nur, DevTools zu öffnen, eine Anfrage zu inspizieren und zu raten: Ist die Regel falsch, passt die Domain nicht, oder hat eine andere Regel stillschweigend Vorrang?

Genau für diese Frage gibt es die 🔍-Schaltfläche im Kopf des Panels. URL eingeben, HTTP-Methode wählen (GET ist vorbelegt), ausführen — der Bericht steht sofort da:

• Welche Regeln greifen — nach Priorität sortiert, jeweils mit Regelname und der Domain, die tatsächlich gepasst hat.
• Was jede Regel schreibt — welche Header eine passende Regel in den Request oder die Response einträgt und ob per set, append oder remove.
• Wer bei Konflikten gewinnt — greifen mehrere Regeln auf denselben Header, nennt der Bericht die Gewinnerin und die Regel, die sie verdrängt.
• Methodenkonflikt mit eigenem Namen — eine Regel, die nur für POST gilt und deshalb nicht teilnehmen kann, wird als Methodenkonflikt ausgewiesen und nicht unter „keine Regel passt“ einsortiert. Das sind zwei verschiedene Ursachen.

Technisch ist das ein reiner Dry Run im Lesemodus: keine Netzwerkanfrage, kein angelegtes oder geändertes DNR-Regelwerk, kein Schreibzugriff auf den Speicher. Die Prüfung läuft durch dieselbe Logik wie der Echtbetrieb — derselbe Regex-Builder, dieselbe Prioritätsleiter — das Ergebnis entspricht also dem, was der Browser bei der nächsten echten Anfrage tut.

Sie fängt auch die leisen Fälle. Regeln greifen domänenbasiert: Groß- und Kleinschreibung egal, Pfad ignoriert, www optional, Subdomains per Schalter. Daran scheitern Regeln, die völlig vernünftig aussehen. Die vollständige URL im Tester macht das sofort sichtbar — eine Diagnose, die andere Header-Erweiterungen nicht bieten, und im Free-Tier enthalten.

Umzug von ModHeader oder Header Editor

Die meisten wechseln das Werkzeug nicht, weil es ihnen nicht gefällt, sondern weil dreißig Header von Hand nachzubauen mühsam ist. Einstellungen → Import liest die JSON-Dateien, die ModHeader und Header Editor exportieren, direkt ein — ohne Konvertierungsskript und ohne Neutippen.

Was mitkommt:

• Domains, inklusive der Option, Subdomains einzuschließen.
• Request- und Response-Header-Einträge, mit set, append und remove unverändert.
• Methodenfilter — eine Regel, die nur bei POST greift, bleibt eine POST-Regel.

Was nicht mitkommt, wird im Bericht ausgewiesen statt still zu verschwinden: Regeln, die an einen bestimmten Tab oder ein Fenster gebunden sind, zeitgesteuerte Regeln, Redirects, das Umschreiben von Response-Bodies und eigene Funktionen. Der Importbericht listet alles auf, sodass Sie vor dem Löschen der alten Erweiterung wissen, was dort noch liegt.

Zwei Voreinstellungen halten den Umzug sicher. Importierte Regeln landen deaktiviert — eine Datei zu lesen schaltet nichts live. Und wo sich ein ursprünglicher Geltungsbereich nicht abbilden lässt, wird er nicht ausgeweitet: Eine auf einen Tab begrenzte Regel wird niemals zu „alle Websites“. VKT Header wirkt domänenbasiert global und nicht pro Tab; ein engerer Ursprungsbereich muss also bewusst neu angelegt werden, statt automatisch angenähert zu werden.

Der Import kostet nichts. Der Export der eigenen Regeln als JSON-Backup gehört zu Premium — sinnvoll, sobald ein Satz entstanden ist, den Sie behalten wollen.

Die praktische Reihenfolge: erst den Importbericht lesen, dann Regeln einzeln aktivieren und jede mit dem Request-Tester aus dem vorigen Abschnitt prüfen.

Head-to-Head-Vergleich

Welche sollten Sie installieren?

• Wählen Sie ModHeader, wenn Sie Umschreibung von Response-Headern, Team-Profile brauchen — oder wenn Sie bereits für das Abonnement zahlen und das globale Modell mit Filtern zu Ihnen passt.
• Wählen Sie VKT Header, wenn Ihre Arbeit die Request-Header sind — API-Tests, UA-Experimente, QA-Demos — und Sie wollen, dass die Regeln nur so lange leben wie die Browser-Sitzung, mit einmaliger Zahlung statt einer Rechnung, die sich erneuert.

Viele Leser wollen beides zugleich, und es ist keine Schande, eines von beiden zu nutzen: Für die meisten Solo-Entwickler ist 2026 die Aufräum-Garantie der entscheidende Faktor. Header-Tools, die das Verschwinden vergessen, sind Header-Tools, die durchsickern.

Häufig gestellte Fragen

Mehr VKT-Tools finden Sie im Erweiterungen-Katalog, oder schreiben Sie an [email protected].