Was zeigt der Set-Cookie Parser für jeden Cookie?

Für jeden Set-Cookie-Header listet er den Namen, den URL-dekodierten Wert und jedes gefundene Attribut — Domain, Path, Expires (mit relativer Zeit), Max-Age, Secure, HttpOnly, SameSite, Priority und Partitioned — plus Warnungen für alles, was kaputt aussieht.

Warum erfordert SameSite=None das Secure-Attribut?

Moderne Browser akzeptieren einen Cross-Site-Cookie (SameSite=None) nur, wenn er auch als Secure markiert ist, sodass er nur über HTTPS reisen kann. Fehlt Secure, weist der Browser den Cookie zurück, und der Parser markiert diese Kombination mit einer Warnung.

Was ist der Unterschied zwischen Max-Age und Expires bei einem Cookie?

Expires setzt ein absolutes Datum; Max-Age setzt eine Lebensdauer in Sekunden ab dem Empfang des Cookies. Sind beide vorhanden, gewinnt Max-Age, also löst das Tool Max-Age gegen die aktuelle Zeit auf und vermerkt, dass es Vorrang vor Expires hat.

Was bedeuten die Cookie-Namenspräfixe __Host- und __Secure-?

Es sind Sicherheitspräfixe, die Browser erzwingen. Ein __Secure--Cookie muss Secure setzen; ein __Host--Cookie muss Secure setzen, Domain weglassen und Path=/ nutzen. Der Parser prüft diese Regeln und warnt, wenn der Name eines Cookies Garantien verspricht, die seine Attribute nicht halten.

Kann dieses Tool auch einen Cookie-Request-Header parsen?

Ja. Wechsle in den Cookie-Header-Modus und füge eine Cookie:-Zeile (oder einen bloßen „a=1; b=2“-String) ein, um eine Tabelle jedes Cookie-Namens und -Werts zu erhalten, den die Anfrage sendet, jeweils URL-dekodiert und kopierbar.

Was ist hier ein Session-Cookie gegenüber einem persistenten Cookie?

Ein Cookie ohne Expires und ohne Max-Age ist ein Session-Cookie — er wird gelöscht, wenn der Browser schließt. Alles mit einem Expires-Datum oder Max-Age ist persistent. Der Parser kennzeichnet jeden Cookie als Session oder Persistent, sodass du es auf einen Blick erkennst.

Set-Cookie & Cookie Header Parser

Füge einen rohen Set-Cookie- oder Cookie-Header ein und sieh jedes Attribut, jede Ablaufzeit und jede Sicherheitswarnung aufgeschlüsselt in deinem Browser.

Der Set-Cookie Parser läuft vollständig in deinem Browser. Die Cookie-Header, Werte und alle darin enthaltenen Tokens werden auf deinem Gerät geparst und niemals zu ArrayKit hochgeladen.

Öffne den HAR Viewer

Über Set-Cookie Parser

Der Set-Cookie Parser nimmt einen rohen Set-Cookie-Response-Header — oder einen ganzen Stapel davon — und schlüsselt jeden Cookie in eine lesbare Tabelle auf: Name, URL-dekodierter Wert, Domain, Path, Expires mit einer freundlichen relativen Zeit, Max-Age und die Flags Secure, HttpOnly, SameSite, Priority und Partitioned. Er markiert die Fehler, die Cookies leise kaputt machen, wie SameSite=None ohne Secure, ein bereits abgelaufenes Datum oder ein __Host--Präfix, das seine Regeln verletzt, und sagt dir, ob jeder Cookie ein Session- oder ein persistenter ist. Füge stattdessen einen Cookie-Request-Header ein, und er listet jeden gesendeten Namen und Wert. Alles wird lokal in deinem Browser geparst, sodass die Header, die du inspizierst, niemals dein Gerät verlassen.

Funktionen

Schlüsselt jeden Set-Cookie-Header in seinen Namen, Wert und jedes Attribut auf
URL-dekodiert den Cookie-Wert und kopiert das rohe name=value auf Wunsch
Parst Expires in ein absolutes Datum plus ein relatives „in 2 Stunden“-Label
Löst Max-Age gegen die aktuelle Zeit auf, um den echten Ablaufmoment zu zeigen
Warnt bei SameSite=None ohne Secure, abgelaufenen Daten und Max-Age von null
Prüft die Namenspräfix-Regeln von __Host- und __Secure- und das Partitioned-Flag
Wechselt in einen Cookie-Request-Header-Modus, der jedes Name/Wert-Paar auflistet
Parst eine oder viele Set-Cookie-Zeilen auf einmal, vollständig in deinem Browser

So verwendest du Set-Cookie Parser

Kopiere einen Set-Cookie-Header aus dem Netzwerk-Panel deines Browsers oder einer Server-Antwort
Füge ihn in das Feld ein — ergänze weitere Set-Cookie-Zeilen, eine pro Zeile, wenn du mehrere hast
Lies die Tabelle pro Cookie für Attribute, Ablaufzeit und hervorgehobene Warnungen
Wechsle in den Cookie-Header-Modus, um stattdessen die Cookie:-Zeile einer Anfrage zu inspizieren

Beispiel

Eingabe

Set-Cookie: track=1; Domain=.example.com; SameSite=None

Ausgabe

track = 1 | Domain=.example.com | SameSite=None | Session
⚠ SameSite=None requires the Secure attribute — browsers will reject this cookie.

Ein SameSite=None-Cookie ohne Secure wird in dem Moment markiert, in dem du es einfügst.

Häufige Fehler & Fehlerbehebung

Mehrere Set-Cookie-Header wurden eingefügt, aber nur der erste wurde geparst. — Setze jeden Set-Cookie-Header in seine eigene Zeile. Verbinde sie nicht mit Kommas — ein gültiger Expires-Wert enthält bereits ein Komma, sodass das Verbinden mit Kommas das Datum beschädigt.
Expires zeigt „could not be parsed as an HTTP date.“ — Nutze das Standard-HTTP-Datumsformat, z. B. Expires=Wed, 21 Oct 2025 07:28:00 GMT. Ein fehlerhaftes oder nicht-GMT-Datum kann nicht zuverlässig gelesen werden.
Ein Cookie-Request-Header wurde als ein Set-Cookie mit seltsamen Attributen gelesen. — Wechsle zum Cookie-Header-Tab, oder stelle der Zeile „Cookie:“ voran, sodass sie als Request-Header aus name=value-Paaren behandelt wird.
Der Wert sieht prozentkodiert aus, wie dark%20mode. — Der Parser URL-dekodiert den Wert für die Anzeige (dark mode), während der Kopier-Button weiterhin das exakte rohe name=value aus dem Header liefert.

Häufig gestellte Fragen

Was zeigt der Set-Cookie Parser für jeden Cookie?: Für jeden Set-Cookie-Header listet er den Namen, den URL-dekodierten Wert und jedes gefundene Attribut — Domain, Path, Expires (mit relativer Zeit), Max-Age, Secure, HttpOnly, SameSite, Priority und Partitioned — plus Warnungen für alles, was kaputt aussieht.
Warum erfordert SameSite=None das Secure-Attribut?: Moderne Browser akzeptieren einen Cross-Site-Cookie (SameSite=None) nur, wenn er auch als Secure markiert ist, sodass er nur über HTTPS reisen kann. Fehlt Secure, weist der Browser den Cookie zurück, und der Parser markiert diese Kombination mit einer Warnung.
Was ist der Unterschied zwischen Max-Age und Expires bei einem Cookie?: Expires setzt ein absolutes Datum; Max-Age setzt eine Lebensdauer in Sekunden ab dem Empfang des Cookies. Sind beide vorhanden, gewinnt Max-Age, also löst das Tool Max-Age gegen die aktuelle Zeit auf und vermerkt, dass es Vorrang vor Expires hat.
Was bedeuten die Cookie-Namenspräfixe __Host- und __Secure-?: Es sind Sicherheitspräfixe, die Browser erzwingen. Ein __Secure--Cookie muss Secure setzen; ein __Host--Cookie muss Secure setzen, Domain weglassen und Path=/ nutzen. Der Parser prüft diese Regeln und warnt, wenn der Name eines Cookies Garantien verspricht, die seine Attribute nicht halten.
Kann dieses Tool auch einen Cookie-Request-Header parsen?: Ja. Wechsle in den Cookie-Header-Modus und füge eine Cookie:-Zeile (oder einen bloßen „a=1; b=2“-String) ein, um eine Tabelle jedes Cookie-Namens und -Werts zu erhalten, den die Anfrage sendet, jeweils URL-dekodiert und kopierbar.
Was ist hier ein Session-Cookie gegenüber einem persistenten Cookie?: Ein Cookie ohne Expires und ohne Max-Age ist ein Session-Cookie — er wird gelöscht, wenn der Browser schließt. Alles mit einem Expires-Datum oder Max-Age ist persistent. Der Parser kennzeichnet jeden Cookie als Session oder Persistent, sodass du es auf einen Blick erkennst.