Set-Cookie-Parser

Fügen Sie mehrzeilige Set-Cookie-Antwortheader ein, um Attribute zu prüfen und riskante SameSite-/Secure-Kombinationen zu markieren.

Cookie-Attributkarten

2 Set-Cookie(s)

#1sessionabc123

path/

httponly(Flag)

secure(Flag)

samesiteLax

Keine offensichtlichen Attributprobleme gefunden

#2preview1

max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone

secure(Flag)

setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

JSON-Vorschau

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

Wenn der Browser Cookies nicht akzeptiert, liegt es oft nicht am Wert, sondern an falschen Set-Cookie-Attributen.

Was ist der Set-Cookie-Parser?

Der Set-Cookie-Parser ist ein Debugging-Tool speziell für den Inhalt von Set-Cookie-HTTP-Antwortheadern. Er teilt den Text nicht nur an Semikolons auf, sondern hilft Entwicklern zu beurteilen: Ist die Cookie-Konfiguration des Servers korrekt, warum akzeptiert der Browser sie nicht, welche Attributkombinationen Sicherheits- oder Kompatibilitätsrisiken bergen, und eignet sich das Set-Cookie für Cross-Site-, SSO-, iframe-, Drittanbieter-Cookie- oder Sitzungsszenarien.

Anders als der Cookie-Header in Anfragen ist Set-Cookie eine Konfigurationsanweisung des Servers an den Browser. Sie enthält nicht nur name=value, sondern auch Attribute wie SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age und Partitioned. Diese Felder bestimmen direkt, ob der Browser das Cookie speichert, wann es abläuft, auf welchen Pfaden und Domains es gültig ist und ob es in Cross-Site-Anfragen gesendet wird. Viele Probleme wie verlorener Login-Status, fehlende Cookies in Anfragen oder in Cross-Origin-Szenarien liegen nicht am Wert selbst, sondern an der Set-Cookie-Attributkonfiguration.

Der Wert dieser Seite liegt darin, diese Attribute aus dem ursprünglichen Antwortheader strukturiert zu extrahieren und statische Prüfungen anhand der tatsächlichen Browserregeln durchzuführen. Zum Beispiel: Fehlt Secure bei SameSite=None, ist Partitioned mit Secure kombiniert, hat der __Host-Präfix eine falsche Domain, ist Max-Age ungültig oder 0, fehlt Max-Age bei Expires. Browser zeigen solche Probleme oft nicht als Syntaxfehler an, sondern lehnen das Cookie stillschweigend ab, daher ist eine toolgestützte Prüfung wichtig.

Wenn Sie nur wissen möchten, welche Cookies in der aktuellen Anfrage enthalten sind, verwenden Sie stattdessen den HTTP-Cookie-Parser. Diese Seite ist für die Fehlerbehebung bei Antwortheadern gedacht: Warum hat der Browser das Cookie nicht gespeichert, gibt es Sicherheitsrisiken in der Konfiguration, ist die Kombination aus Cross-Site- und Sicherheitsattributen korrekt.

Anwendungsfälle

Schnelles Lokalisieren von Konfigurationsproblemen mit SameSite, Secure, HttpOnly, Path oder Domain, wenn der Browser Cookies ablehnt
Prüfen, ob SameSite=None in Drittanbieteranmeldungs-, SSO-, iframe-Einbettungs- oder Cross-Site-Anfrageszenarien korrekt mit Secure kombiniert ist
Batch-Prüfung von Cookie-Antworten von Schnittstellen bei Sicherheitsaudits auf fehlendes HttpOnly/SameSite oder risikoreiche Attributkombinationen
Überprüfen, ob __Host-/__Secure-Präfix-Cookies die Browserbedingungen erfüllen, um stillschweigende Ablehnung zu vermeiden
Prüfen, ob Partitioned und Secure beim Debuggen von Partitioned Cookies/CHIPS gleichzeitig deklariert sind
Vergleichen von Set-Cookie-Antwortheadern aus Entwicklungs-, Test- und Produktionsumgebungen zur Fehlerbehebung bei Login-Problemen nach Umgebungswechseln

Anleitung

Kopieren Sie den Inhalt der Set-Cookie-Antwortheader (mehrzeilig unterstützt) aus Browser-DevTools, Paketanalyse-Tools oder Server-Logs
Fügen Sie ihn in den Eingabebereich ein; das Tool entfernt automatisch das Präfix Set-Cookie: und analysiert jede Zeile
Zeigen Sie Namen, Werte, URL-dekodierte Werte, Attributkarten und Warnhinweise für jedes Cookie an
Kopieren Sie den Rohheader oder zeigen Sie die JSON-Vorschau an, um Ergebnisse an Backend-Entwickler zu senden oder in Issues/Testskripte einzufügen

Funktionen

Unabhängige Analyse mehrerer Set-Cookie-Header: Jede Zeile wird als separate Karte angezeigt, mit Namen, Rohwert, URL-dekodiertem Wert und Attributen
Automatische Prüfung auf 14 häufige Probleme: Deckt SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, __Host-/__Secure-Präfixe und Partitioned ab
Vollständige Attributzerlegung: Strukturierte Anzeige nach SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned und weiteren Feldern
Menschenlesbare Max-Age-Umrechnung: Sekunden werden automatisch in Minuten, Stunden und Tage umgerechnet
Mehrzeilige Stapelverarbeitung: Fügen Sie gesamte Set-Cookie-Antwortheader direkt aus DevTools oder Paketanalyse-Tools ein
Rohheader-Kopie und JSON-Vorschau: Zum Weiterleiten an Backend-Entwickler oder zum Erstellen von Dokumenten, Issues und Testfällen
Lokale Verarbeitung ohne Upload: Sensible Sessions, Tokens und Login-Cookies werden im Browser analysiert und verlassen Ihr Gerät nicht

Wann verwende ich den Set-Cookie-Parser, wann die anderen Seiten?

Zwischen "Was hat der Server gesetzt" und "Was wird tatsächlich in Anfragen gesendet" besteht ein wichtiger Unterschied – verwechseln Sie das nicht.

Tool	Geeignete Eingabe	Am besten geeignet für	Kernvorteil
Set-Cookie-Parser (diese Seite)	Set-Cookie-Antwortheader	Fehlerbehebung bei nicht akzeptierten Cookies, nicht funktionierenden Cross-Site-Cookies und Risiken in der Sicherheitskonfiguration	Vollständige Attributzerlegung mit automatischer Prüfung auf 14 häufige Konfigurationsfehler
HTTP-Cookie-Parser	Cookie-Anforderungsheader, document.cookie	Prüfen, welche Cookies tatsächlich in Anfragen enthalten sind, ob Werte URL-kodiert sind und ob es doppelte Namen gibt	Fokussiert auf die Zerlegung von Name-Wert-Paaren in Anforderungsheadern und standardisierte AusgabeHTTP-Cookie-Parser öffnen
Cookie-Parser	Gemischte Cookie-Strings und Set-Cookie-Fehlerbehebung	Wenn Sie die Herkunft der Daten nicht genau kennen oder schnell zwischen Cookie- und Set-Cookie-Modus wechseln möchten	Allgemeiner Einstiegspunkt für Cookie-Debugging, unterstützt zudem Export im Netscape-Cookie-DateiformatCookie-Parser öffnen

Best Practices

Prüfen Sie zuerst, ob das Problem beim Setzen oder beim Senden des Cookies liegt

Wenn der Browser das Cookie überhaupt nicht speichert, beginnen Sie mit dieser Seite. Wenn das Cookie bereits gespeichert ist, aber in nachfolgenden Anfragen fehlt, verwenden Sie zusätzlich den HTTP-Cookie-Parser. Set-Cookie und Cookie-Anforderungsheader sind zwei unterschiedliche Phasen.

Prüfen Sie bei Cross-Site-Szenarien zuerst die Kombination aus SameSite=None und Secure

Der häufigste Fehler bei SSO, Drittanbieteranmeldungen, iframe-Einbettungen und Cross-Origin-Anfragen ist SameSite=None ohne Secure. Beseitigen Sie zuerst dieses Problem, bevor Sie Serverlogik oder Browsereinstellungen prüfen.

Prüfen Sie bei Host-/Secure-Präfixen nicht nur den Namen, sondern alle Bedingungen

Viele Teams denken, dass ein __Host- oder __Secure-Präfix im Cookienamen bereits für Sicherheit sorgt, aber wenn Secure, Path=/ oder Domain nicht korrekt konfiguriert sind, lehnt der Browser das Cookie trotzdem ab.

Bewahren Sie beim Dokumentieren und Reproduzieren von Issues sowohl den Rohheader als auch die JSON-Version auf

Der Rohheader eignet sich zum Abgleich mit Backend-Entwicklern und Betriebsteams; die JSON-Version lässt sich in Issues, Testfälle und Skripte einfügen. Beides zusammen ist besser als nur ein Screenshot aus DevTools.

Häufig gestellte Fragen

Was ist der Unterschied zwischen dem Set-Cookie-Parser und dem Cookie-Anforderungsheader-Parser?

Der Set-Cookie-Parser ist für Antwortheader des Servers gedacht und prüft, ob der Browser das Cookie akzeptiert und ob die Attribute korrekt sind. Der Cookie-Anforderungsheader-Parser analysiert Anfragen des Browsers und zeigt, welche Cookies tatsächlich gesendet werden. Wenn Sie Probleme mit SameSite, HttpOnly, Secure, Path, Domain, Expires oder Max-Age beheben, verwenden Sie diese Seite.

HTTP-Cookie-Parser

Warum schreibt der Browser das Cookie nicht, obwohl er die Antwort erhalten hat?

Genau dafür ist dieses Tool optimal. Häufige Ursachen: SameSite=None ohne Secure, Secure-Cookie auf HTTP-Seiten, __Host-Präfixverstöße, Partitioned ohne Secure, falsche Path-/Domain-Konfiguration, ungültiges Max-Age oder Max-Age=0 sowie Drittanbieter-Cookie-Richtlinien des Browsers.

Welche häufigen Set-Cookie-Risiken prüft das Tool?

Diese Seite erkennt automatisch 14 häufige Probleme: SameSite=None ohne Secure, ungültiger SameSite-Wert, Partitioned ohne Secure, fehlendes HttpOnly/Path/SameSite, __Host-Präfix ohne Secure/Path=/ oder mit falscher Domain, __Secure-Präfix ohne Secure, ungültiges Max-Age, Max-Age=0, Domain mit führendem Punkt sowie Expires ohne Max-Age.

Warum muss SameSite=None immer mit Secure kombiniert werden?

Moderne Browser erfordern, dass Cross-Site-Cookies mit SameSite=None auch das Secure-Attribut haben, sonst werden sie abgelehnt. Dies tritt häufig bei Drittanbieteranmeldungen, SSO, iframe-Einbettungen und Cross-Origin-Anfragen auf.

Warum werden Cookies mit Host- oder Secure-Präfix vom Browser abgelehnt?

__Host- und __Secure- sind Sicherheitspräfixe mit strengen Regeln. __Host- erfordert Secure, Path=/ und keine Domain-Angabe; __Secure- erfordert mindestens Secure. Bei Verstößen ignoriert der Browser das Cookie.

Wie sind Max-Age und Expires zu interpretieren?

Max-Age gibt die relative Gültigkeit in Sekunden an und hat Vorrang vor Expires. Expires ist ein absoluter Zeitpunkt, der von der Client-Uhr abhängt. Viele Server setzen nur Expires ohne Max-Age, was bei Zeitversätzen oder Zeitzonenunterschieden zu Fehlinterpretationen führen kann.

Eignet sich das Tool zur Fehlerbehebung bei Cross-Site- und Drittanbieter-Cookies?

Ja. Ob Drittanbieteranmeldung, SSO, iframe-Einbettung, Cross-Origin-Schnittstellen oder CHIPS (Partitioned Cookie) – dieses Tool zeigt schnell, ob die Kombination aus SameSite, Secure und Partitioned korrekt ist.

Können Analyseergebnisse kopiert oder exportiert werden?

Ja. Sie können den ursprünglichen Set-Cookie-Header mit einem Klick kopieren oder die strukturierte JSON-Vorschau anzeigen, um Namen, Werte, Attribute und Warnungen in Issues, Dokumente, Testskripte oder Debug-Notizen einzufügen.

Werden meine kopierten Session- oder Token-Daten an einen Server hochgeladen?

Nein. Die Analyse des Set-Cookie-Inhalts, URL-Decodierung, Attributzerlegung und Warnungsprüfung erfolgen vollständig lokal im Browser, sensible Antwortheader werden nicht an Server übermittelt.

Glossar

Set-Cookie: HTTP-Antwortheader, mit dem der Server den Browser anweist, ein Cookie zu speichern. Eine Antwort kann mehrere Set-Cookie-Header enthalten, jeder entspricht normalerweise einem Cookie.
SameSite: Attribut, das steuert, ob Cookies in Cross-Site-Anfragen gesendet werden. Gängige Werte: Strict, Lax, None; bei None ist meist Secure erforderlich.
HttpOnly: Wenn gesetzt, kann JavaScript das Cookie nicht über document.cookie lesen, reduziert das Risiko von XSS-basiertem Sitzungsdiebstahl.
Secure: Wenn gesetzt, sendet der Browser das Cookie nur über HTTPS-Verbindungen (ausgenommen localhost), um sensible Cookies in unverschlüsselten HTTP-Verbindungen zu schützen.
Max-Age: Relative Gültigkeitsdauer des Cookies in Sekunden. Hat normalerweise Vorrang vor Expires und sollte explizit vom Server gesetzt werden.
Expires: Absoluter Ablaufzeitpunkt des Cookies, abhängig von der lokalen Uhrzeit des Clients. Bei alleiniger Verwendung ist der Debugging-Aufwand höher als bei Max-Age.
Path: Beschränkt das Cookie auf URL-Pfade mit diesem Präfix. Wenn der Path nicht übereinstimmt, wird das Cookie in nachfolgenden Anfragen nicht gesendet, auch wenn es gespeichert ist.
Domain: Beschränkt das Cookie auf einen Domain-Bereich. Ohne Angabe gilt es nur für den aktuellen Host; mit Angabe kann es auch auf Subdomains wirken.
Partitioned (CHIPS): Partitionierte Speicherlösung für Drittanbieter-Cookies, als Alternative nachdem Browser Drittanbieter-Cookies zunehmend einschränken. Aktuelle Implementierungen erfordern meist Secure.
__Host- / __Secure-Präfixe: Von Browsern unterstützte sichere Cookie-Namenspräfixe mit strengen Regeln. Bei Verstößen lehnt der Browser das Cookie ab.

Vergleichstabelle der drei SameSite-Strategien

Bei der Fehlerbehebung von Cross-Site-Cookies prüfen Sie zuerst das Verhalten von SameSite und dann, ob Secure fehlt.

SameSite-Wert	Cross-Site-Top-Level-Navigation (GET)	Cross-Site-Unterressourcen (img/iframe/script)	Cross-Site-POST-Formulare	Cross-Site-XHR/fetch	Secure erforderlich?
Strict	Nicht senden	Nicht senden	Nicht senden	Nicht senden	Nein
Lax (Standard)	Senden	Nicht senden	Nicht senden	Nicht senden	Nein
None	Senden	Senden	Senden	Senden	Secure muss gesetzt sein

Tabelle häufiger Set-Cookie-Debugging-Probleme

Wenn der Browser Cookies stillschweigend ablehnt, prüfen Sie zuerst diese Punkte – das geht oft schneller als den Antworttext zu durchsuchen.

Symptom	Wahrscheinliche Ursache	Zuerst prüfen
Browser speichert Cookie überhaupt nicht	SameSite=None ohne Secure, Präfixverstöße oder ungültige Attributkombination	Prüfen Sie die Warnhinweise und Attributkarten auf dieser Seite
Funktioniert nicht in Cross-Site-/iframe-Szenarien	Zu strenges SameSite, fehlendes Secure oder Drittanbieterrichtlinien	Fokus auf SameSite, Secure, Partitioned
Cookie läuft sofort nach dem Setzen ab	Max-Age=0, ungültiges Max-Age, fehlerhaftes Expires-Datum	Zuerst Max-Age prüfen, dann Expires
__Host-/__Secure-Cookie funktioniert nicht	Secure, Path=/ oder Domain-Bedingungen nicht erfüllt	Prüfen Sie, ob Präfixwarnungen angezeigt werden
Funktioniert in Entwicklungsumgebung, aber nicht in Produktion	Unterschiede bei HTTPS, Domain, Path, SameSite oder Proxy-Antwortheadern	Kopieren Sie den Rohheader und vergleichen Sie die Set-Cookie-Antworten verschiedener Umgebungen

Privacy & Security

Die Analyse des Set-Cookie-Antwortheaders, URL-Decodierung, Attributzerlegung und Prüfung auf 14 Warnkategorien erfolgen vollständig lokal im Browser. Eingefügte Sessions, Tokens und Login-Cookies werden nicht an Server übermittelt.

Set-Cookie-Parser