| 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.
Fokussierter, wenn Sie nur sehen möchten, welche Cookies die Anfrage tatsächlich gesendet hat
Tiefergehend, wenn Sie verstehen möchten, warum der Browser ein Cookie abgelehnt hat
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.
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 |
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 ParserSet-Cookie ParserViele 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.
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.
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 CodeUnterstü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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
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 |
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.
