Cookie-Parser

Cookie-Zeichenkette einfügen (durch Semikolon getrennt)

Name	Wert	Betrieb
Auflösung anzeigen nach oben

Netscape-Datei kann Curl-buse;no Domain wurde durch eine Platzhalter-Domain ersetzt.

Eine einzige Seite, um sowohl Cookie-Request-Header als auch Set-Cookie-Response-Header bei Login-, API- und Browser-Debugging zu verstehen.

Was ist ein Cookie-Parser?

Ein Cookie-Parser wandelt Cookie-Text aus Browsern, Frontend-Code, API-Tools oder Server-Responses in strukturierte Ergebnisse um. Er versucht nicht, Cookie-Theorie abstrakt zu erklären, sondern beantwortet die Fragen, die in echtem Debugging auftauchen: Welche Cookies wurden mit der aktuellen Anfrage tatsächlich gesendet? Welche Attribute stehen im Set-Cookie-Response-Header? Warum sieht SameSite / Secure / HttpOnly korrekt aus, obwohl der Browser das Cookie trotzdem ablehnt? Wurde der Cookie-Wert URL-kodiert? Und wie lässt sich das Ergebnis in Skripten oder Kommandozeilen-Tools weiterverwenden?

Ein häufiger Fehler einfacher Tools ist es, document.cookie, den Cookie-Request-Header und den Set-Cookie-Response-Header so zu behandeln, als hätten sie dieselbe Eingabeform. Das stimmt nicht. document.cookie und Request-Cookies betrachtet man am besten als flache name=value-Paare, bei denen es vor allem darum geht zu prüfen, ob die Anfrage die richtigen Cookies mitgeschickt hat. Set-Cookie ist dagegen ein Server-zu-Browser-Response-Header, bei dem Sie kontrollieren müssen, ob SameSite, Path, Domain, Expires, Max-Age, HttpOnly und Secure korrekt gesetzt sind.

Diese Seite funktioniert als allgemeiner Einstiegspunkt, wenn Sie noch nicht sicher sind, welche Art von Cookie-Text Sie vor sich haben, oder wenn Sie einen vollständigen Login-State-Fehler untersuchen und sowohl vergleichen müssen, was die Anfrage gesendet hat, als auch was der Server zurückgegeben hat. Sie können auf einer Seite zwischen Cookie-String-Modus und Set-Cookie-Modus wechseln und das Ergebnis schnell analysieren, prüfen, filtern, kopieren und exportieren.

Im Gegensatz zu simplen Online-Tools, die nur ein split(;) machen, ist dieser Parser auf Lesbarkeit und Wiederverwendung in echten Debugging-Szenarien ausgelegt. Er behält den Rohwert bei und zeigt zusätzlich eine dekodierte Version an, stellt Attributtabellen bereit, exportiert JSON und Netscape Cookie File und lässt doppelte Cookies sichtbar, statt gerade das Signal wegzuautomatisieren, das Sie zur Fehlerdiagnose brauchen.

Wenn Sie später einen noch fokussierteren Workflow für Request-Header brauchen, nutzen Sie den HTTP Cookie Parser. Wenn Sie verstehen müssen, warum der Browser ein Cookie abgelehnt hat, ob SameSite=None ohne Secure gesetzt wurde oder ob Sicherheitsattribute in Set-Cookie ungültig sind, wechseln Sie zum Set-Cookie Parser. Diese Seite ist am besten als allgemeines Cookie-Debugging-Hub und Routing-Seite zu verstehen.

Anwendungsfälle

Einen document.cookie-String aus DevTools oder Logs nehmen und schnell in einzelne Cookie-Einträge zerlegen
Mehrzeilige Set-Cookie-Header aus dem Netzwerk-Panel einfügen, um zu sehen, warum der Browser ein Cookie abgelehnt hat
Verlorene Login-Zustände, fehlende Cross-Site-Cookies und Konflikte durch doppelte Cookie-Namen untersuchen
URL-kodierte Cookie-Werte in lesbaren Text umwandeln, um den tatsächlichen Inhalt zu prüfen
Analysierte Cookies in JSON für Skripte, Tickets, Dokumentation oder Testfälle umwandeln
Netscape Cookie File-Text für curl, Crawler oder importbasierte Tools erzeugen
Als allgemeine Cookie-Triage-Seite bei Frontend-, QA-, Ops- und Crawler-Debugging verwenden

Anleitung

Zuerst die Quelle einordnen: Cookie-String-Modus für document.cookie, Request-Header oder Logs verwenden und Set-Cookie-Modus für Response-Header
Den Rohtext der Cookies in das Eingabefeld einfügen; das Tool trennt Namen, Werte und Attribute automatisch
URL-dekodierte Werte aktivieren, wichtige Felder filtern und bei Bedarf Warnungen zu doppelten Namen oder Attributtabellen prüfen
Den normalisierten Text kopieren, JSON exportieren oder ein Netscape Cookie File für den nächsten Debugging-Schritt erzeugen

Funktionen

Zwei Analysemodi für document.cookie / Cookie-Request-Header und mehrzeilige Set-Cookie-Response-Header
Automatische Aufschlüsselung von Name, Wert und Attributen mit Rohwerten, URL-dekodierten Werten sowie SameSite / Secure / HttpOnly / Path / Domain / Expires / Max-Age-Feldern
Warnungen bei doppelten Namen, um Path-Konflikte, überlappende Scopes und instabiles Session-Verhalten zu finden
Strukturierter JSON-Export für Skripte, API-Debugging und reproduzierbare Fehlerberichte
Netscape Cookie File-Generierung für curl und Crawler-Toolchains, die dieses Format noch verwenden
Lokale Verarbeitung, damit Session-, Token- und Login-Cookies Ihr Gerät nicht verlassen
Klare Trennung zwischen Request-seitigem und Response-seitigem Cookie-Debugging als praktischer allgemeiner Einstiegspunkt

Wie wählt man zwischen Cookie-Parser-Tools?

Diese Seite eignet sich gut als allgemeiner Einstieg für Cookie-Debugging. Wenn Sie aber bereits genau wissen, welche Datenart vorliegt, ist ein spezialisiertes Tool schneller.

Tool	Ideale Eingabe	Am besten für	Stärke
Cookie-Parser (diese Seite)	Cookie-Strings, document.cookie, mehrzeiliges Set-Cookie	Wenn der Eingabetyp noch unklar ist oder Sie Request- und Response-Cookies an einer Stelle behandeln möchten	Zwei Modi, JSON-/Netscape-Export und ein praktisches zentrales Cookie-Debugging-Hub
HTTP Cookie Parser	Cookie-Request-Header und document.cookie-artige Strings	Prüfen, welche Cookies die Anfrage tatsächlich gesendet hat, ob Namen doppelt vorkommen und ob Werte URL-kodiert sind	Stärker auf Request-seitige Name/Wert-Analyse für Sessions und Login-Zustände fokussiertHTTP Cookie Parser öffnen
Set-Cookie Parser	Vom Server zurückgelieferte Set-Cookie-Response-Header	Prüfen, warum der Browser ein Cookie abgelehnt hat und ob SameSite / Secure / HttpOnly problematisch sind	Tiefere Attributanalyse für Sicherheitseinstellungen und Browser-PoliciesSet-Cookie Parser öffnen

Best Practices

Zuerst klären, ob Sie einen Request- oder Response-Header vor sich haben

Wenn der Text aus Frontend-Code, document.cookie, Request-Logs oder einem curl-Header stammt, beginnen Sie mit dem Cookie-String-Modus. Wenn er aus den Response Headers im Browser-Netzwerk-Panel stammt, wechseln Sie in den Set-Cookie-Modus, sonst lesen Sie Attribute fälschlich als normale Schlüssel-Wert-Paare.

HTTP Cookie Parser Set-Cookie Parser

Beim Blick auf URL-dekodierte Werte den Rohwert nicht verlieren

Viele Cookie-Werte sind URL-kodiert. Im Debugging sollten Sie sowohl den Rohwert als auch den dekodierten Wert sichtbar halten, besonders wenn es um Signaturen, Base64, JWT oder serverseitige Doppel-Kodierung geht.

Bei doppelten Namen zuerst Path und Domain prüfen, nicht sofort deduplizieren

Doppelte Cookies deuten oft auf unterschiedliche Pfade, unterschiedliche Domains oder Restwerte aus älteren Flows hin. Automatische Deduplizierung kann die eigentliche Ursache verstecken. Lassen Sie Duplikate sichtbar und vergleichen Sie sie mit Request-Pfad, Scope und Set-Cookie-Konfiguration.

Exportformat nach dem nächsten Verarbeitungsschritt wählen

Wenn Sie das Ergebnis nur in Doku, Tickets oder Skripte einfügen möchten, ist JSON meist klarer. Wenn Sie das Ergebnis in curl, einen Crawler oder ein Tool mit Cookie-Datei-Import einspeisen wollen, wählen Sie Netscape Cookie File.

curl zu Code

Häufig gestellte Fragen

Welche Eingabeformate unterstützt dieser Cookie-Parser?

Unterstützt werden zwei Haupttypen von Eingaben: flache name=value; name2=value2-Strings wie document.cookie oder ein Cookie:-Request-Header sowie mehrzeilige Set-Cookie-Response-Header aus dem Netzwerk-Panel des Browsers. Der erste Typ eignet sich, um zu sehen, welche Cookies tatsächlich mit der Anfrage gesendet wurden. Der zweite ist besser, um SameSite, Secure, HttpOnly, Path, Domain, Expires und Max-Age zu prüfen.

Was ist der Unterschied zwischen Cookie-Request-Header und Set-Cookie-Response-Header?

Ein Cookie-Request-Header ist die flache Liste von Schlüssel-Wert-Paaren, die der Browser an den Server sendet. Er enthält keine Attribut-Metadaten. Set-Cookie ist der Response-Header, den der Server an den Browser zurückgibt. Jede Zeile beschreibt eine vollständige Cookie-Konfiguration und kann zusätzlich zu Name und Wert auch Path, Domain, Expires, SameSite, Secure, HttpOnly und weitere Attribute enthalten. Nutzen Sie Cookie-Parsing, um zu debuggen, was die Anfrage gesendet hat, und Set-Cookie-Parsing, um zu verstehen, warum der Browser ein Cookie akzeptiert oder ablehnt.

Warum sieht der Cookie-Wert unlesbar aus?

Viele Cookie-Werte sind URL-kodiert. %3D bedeutet zum Beispiel = und %2F bedeutet /. Das Tool behält den Rohwert bei und zeigt zusätzlich die URL-dekodierte Version an, damit Sie den tatsächlichen Inhalt prüfen können, ohne die ursprüngliche Eingabe zu verlieren.

Warum erscheinen doppelte Cookie-Namen?

Doppelte Namen können durch unterschiedliche Paths, unterschiedliche Domains oder wiederholte Schreibvorgänge während des Debuggings entstehen. Das Duplikat ist oft ein wichtiger Hinweis. Deshalb warnt das Tool davor, anstatt Einträge automatisch zusammenzuführen und damit die eigentliche Ursache zu verstecken.

Wann sollte ich JSON-Export und wann Netscape-Export verwenden?

JSON ist besser, wenn Sie mit Skripten, Testfällen, API-Dokumentation oder Log-Analysen weiterarbeiten möchten. Netscape Cookie File ist besser, wenn Sie Cookies in Tools oder Kommandozeilen-Workflows wiederverwenden wollen, die dieses Format unterstützen, zum Beispiel curl -b. JSON ist strukturierter, Netscape ist vor allem für Kompatibilität gedacht.

Hilft dieses Tool bei verlorenen Login- oder Session-Zuständen?

Ja. Sie können zuerst im Cookie-Modus prüfen, welche Cookies die Anfrage tatsächlich gesendet hat, und dann in den Set-Cookie-Modus wechseln, um zu sehen, ob serverseitige Attribute problematisch sind, etwa SameSite=None ohne Secure, ein nicht passender Path, ein ungültiges Max-Age oder eine falsche Domain-Reichweite.

Wenn ich nur Request-Cookies prüfen will, warum sollte ich diesen kombinierten Parser verwenden?

Der kombinierte Parser ist nützlich, wenn Ihr Debugging sowohl document.cookie als auch Set-Cookie betreffen kann und Sie einen gemeinsamen Einstiegspunkt möchten. Wenn Sie bereits wissen, dass Sie nur Request-Cookies benötigen, ist der dedizierte HTTP Cookie Parser fokussierter. Wenn Sie nur Response-Header brauchen, geht der Set-Cookie Parser bei Attributvalidierung und Sicherheitsprüfungen tiefer.

Werden Session-, Token- oder Login-Cookies, die ich hier einfüge, an einen Server hochgeladen?

Nein. Cookie-Parsing, URL-Dekodierung, JSON-Vorschau und Netscape-Textgenerierung laufen lokal im Browser. Nichts von dem, was Sie einfügen, wird an einen Server gesendet.

Erkennt das Tool SameSite, Secure und HttpOnly in Set-Cookie automatisch?

Ja. Das Tool analysiert jede Set-Cookie-Zeile und zeigt strukturierte Felder wie SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age und Partitioned an. Sie müssen also keine Semikolons im Roh-Header mehr von Hand zählen.

Kann ich das analysierte Ergebnis direkt in curl oder Skripten weiterverwenden?

Ja. Im Request-Header-Modus können Sie normalisierten Cookie-Inhalt kopieren. Der kombinierte Parser exportiert außerdem JSON und Netscape Cookie File-Text, damit Sie das Ergebnis in curl, Crawler-Skripten, API-Testtools oder Automatisierungsaufgaben weiterverwenden können.

Glossar

Cookie-Request-Header: Die Menge von Name-Wert-Paaren, die der Browser automatisch in eine HTTP-Anfrage einfügt, meist in der Form name1=value1; name2=value2. Er enthält nur die Werte, die mit der aktuellen Anfrage gesendet werden, nicht aber Attribute wie Path, Domain, HttpOnly oder SameSite.HTTP Cookie Parser
Set-Cookie-Response-Header: Der HTTP-Response-Header, mit dem ein Server ein Cookie setzt. Jede Zeile definiert in der Regel genau ein Cookie und kann zusätzlich zu name=value auch Path, Domain, Expires, Max-Age, SameSite, Secure, HttpOnly und weitere Attribute enthalten.Set-Cookie Parser
document.cookie: Die Cookie-String-Schnittstelle, die Frontend-Skripte lesen können. Sie sieht meistens wie mehrere durch Semikolon getrennte name=value-Paare aus. HttpOnly-Cookies sind darin nicht enthalten und vollständige Set-Cookie-Attributinformationen ebenfalls nicht.
SameSite: Ein Attribut, das steuert, ob Cookies in Cross-Site-Anfragen gesendet werden. Übliche Werte sind Strict, Lax und None. Es ist zentral bei Cross-Site-Login-Zuständen, SSO und eingebetteten Seiten.
HttpOnly: Ein Sicherheitsattribut von Set-Cookie. Wenn es gesetzt ist, kann Frontend-JavaScript das Cookie nicht über document.cookie lesen. Das hilft vor allem, Session-Diebstahl durch XSS zu erschweren.
Secure: Ein Sicherheitsattribut von Set-Cookie. Wenn es gesetzt ist, wird das Cookie nur über HTTPS-Verbindungen gesendet, mit localhost als besonderer lokaler Ausnahme.
Netscape Cookie File: Ein seit Langem existierendes Textformat für Cookies, das von vielen Kommandozeilen-Tools, Crawler-Workflows und Import-Skripten weiterhin unterstützt wird.
URL-kodierter Cookie-Wert: Ein Cookie-Wert, der Sonderzeichen per Prozentkodierung darstellt, zum Beispiel %2F oder %3D. Beim Debugging möchten Sie den Rohwert meist mit dem URL-dekodierten Wert vergleichen.URL Encode Tool
Doppelter Cookie-Name: Derselbe Cookie-Name erscheint mehr als einmal in einer Anfrage, oft wegen unterschiedlicher Paths, Domains oder historischer Restwerte. Duplikate können ein direkter Hinweis auf instabilen Login-State oder Scope-Konflikte sein.

Kurzübersicht über die drei typischen Cookie-Eingabeformen

Viele Cookie-Debugging-Probleme entstehen, weil die Eingabeform schon vor dem eigentlichen Parsing falsch eingeordnet wird.

Eingabetyp	Typisches Beispiel	Enthält	Besseres Tool
document.cookie / Cookie-Request-Header	`session=abc; theme=dark; lang=zh-CN`	Nur flache name=value-Paare ohne Attribute	Cookie-String-Modus auf dieser Seite oder der HTTP Cookie Parser
Set-Cookie-Response-Header	`session=abc; Path=/; HttpOnly; Secure; SameSite=Lax`	name=value plus Sicherheits- und Lebensdauer-Attribute	Set-Cookie-Modus auf dieser Seite oder der Set-Cookie Parser
Netscape Cookie File	`.example.com TRUE / FALSE 0 sid abc123`	Domain, Pfad, Secure-Flag, Ablaufzeit, Name und Wert	Diese Seite kann das Format für curl und Skripte erzeugen

Tabelle häufiger Cookie-Debugging-Probleme

Wenn Sie Cookies debuggen, trennen Sie zuerst fehlende Request-Cookies von Browser-seitigen Ablehnungen.

Symptom	Wahrscheinliche Ursache	Zuerst prüfen
Das Ziel-Cookie fehlt komplett in der Anfrage	Das Cookie wurde nie erfolgreich geschrieben oder Path-/Domain-Scope passt nicht	Zuerst den Set-Cookie-Modus prüfen, dann den Request-Header-Modus
Cross-Site-Anfragen senden keine Cookies	SameSite-Beschränkungen, fehlendes Secure oder Browser-Richtlinien für Third-Party-Cookies	Zuerst prüfen, ob SameSite=None mit Secure kombiniert ist
Der Cookie-Wert wirkt unlesbar	Der Wert wurde URL-kodiert oder serverseitig zusätzlich in Base64 / JWT verpackt	Die dekodierte Ansicht öffnen und danach bei Bedarf mit JWT / Base64 weiterprüfen
Cookies mit gleichem Namen verhalten sich instabil	Es existieren mehrere Schreibvorgänge unter verschiedenen Paths oder Domains	Duplikate sichtbar lassen und Scope sowie Schreibquelle vergleichen
curl oder Skripte können Browser-Cookies nicht direkt wiederverwenden	Es fehlt ein standardisiertes Exportformat	Auf JSON-Export oder Netscape Cookie File-Export wechseln

Privacy & Security

Cookie-Analyse, URL-Dekodierung, JSON-Vorschau und Netscape-Textgenerierung finden lokal im Browser statt. Session-, Token-, Login-Cookies und kopierte Header werden nicht an einen Server übertragen.