Blicken Sie in jedes JWT – Header, Payload und Ablaufdatum

Füge das codierte JWT (die lange eyJ…-Zeichenfolge) in das Eingabefeld ein. Das Tool trennt es an den beiden Punkten, decodiert Header und Payload per Base64URL und zeigt das JSON für beide sowie das rohe Signatursegment an – und das ganz ohne Netzwerkanfrage.

Nein. Der Decoder parst lediglich das Token – er prüft die Signatur nicht gegen einen geheimen oder öffentlichen Schlüssel, da die Verifizierung das Schlüsselmaterial des Ausstellers erfordert. Verwenden Sie für die Verifizierung im Produktivbetrieb eine serverseitige JWT-Bibliothek; dieses Tool dient der Inspektion und dem Debugging.

Du erhältst den Header (Algorithmus und Key-ID), die Payload-Claims (sub, iss, aud, iat, exp sowie alle benutzerdefinierten Claims) und die rohe Signatur. Standard-Zeitstempel-Claims werden als gut lesbare Datumsangaben formatiert, sodass du veraltete Tokens auf einen Blick erkennst.

Enthält die Payload den standardmäßigen „exp"-Claim, vergleicht das Tool ihn mit der aktuellen Zeit und zeigt entweder „Gültig bis" oder „Token abgelaufen am" mit dem genauen Zeitstempel an. Tokens ohne exp-Claim werden als ohne Ablaufdatum ausgewiesen.

Wer die Payload eines JWT lesen kann, kann es bis zum Ablauf verwenden – Produktiv-Tokens gehören daher in private Tools. Dieser Decoder läuft vollständig in deinem Browser und überträgt das Token niemals; die sicherere Regel ist jedoch, nach Möglichkeit nur kurzlebige Entwicklungs-Tokens zu decodieren.

Ein JWT besteht aus drei Base64URL-kodierten, durch Punkte getrennten Segmenten: Header (Signaturalgorithmus), Payload (die Claims, denen der Aussteller den Prüfer vertrauen lassen will) und Signatur (ein MAC oder eine digitale Signatur über header.payload). Zum Dekodieren wird nie ein Schlüssel benötigt – nur zur Verifizierung.

Ein kompaktes, URL-sicheres Token aus drei Base64URL-Segmenten – Header, Payload und Signatur –, das signierte Angaben wie eine Benutzer-ID und eine Ablaufzeit enthält. Es wird häufig für zustandslose Login-Sitzungen und zur Absicherung von API-Anfragen verwendet. Fügen Sie oben eines ein, um Header und Payload zu untersuchen.

Fügen Sie unter dem decodierten Header und der Payload das Signaturgeheimnis (für HS256) oder den öffentlichen Schlüssel des Ausstellers im PEM- oder JWK-Format (für RS256, ES256 und ähnliche) in das Feld „Signatur verifizieren“ ein und klicken Sie dann auf „Verifizieren“. Das eingeblendete Abzeichen meldet, ob die Signatur gültig oder ungültig ist oder einen Algorithmus verwendet, den der browserseitige Prüfer nicht unterstützt — alles lokal berechnet, ohne Token oder Schlüssel irgendwohin zu senden.

Für HMAC-Algorithmen wie HS256 fügst du die rohe gemeinsame Geheimzeichenkette ein. Für asymmetrische Algorithmen wie RS256, RS384 oder ES256 benötigst du den öffentlichen Schlüssel des Ausstellers – niemals den privaten Schlüssel –, bereitgestellt als PEM-Block oder als JWK; das Einfügen der falschen Hälfte eines asymmetrischen Schlüsselpaars lässt die Verifizierung fehlschlagen, obwohl der Token gültig ist.

Das Panel „Signatur prüfen“ unterstützt jeden gängigen JOSE-Algorithmus: HS256/384/512 (HMAC mit einem gemeinsamen Geheimnis), RS256/384/512 (RSASSA-PKCS1-v1_5 mit einem öffentlichen RSA-Schlüssel), PS256/384/512 (RSA-PSS mit einem öffentlichen RSA-Schlüssel) und ES256/384/512 (ECDSA über die passende Kurve P-256/P-384/P-521). Mit „none“ oder einem beliebigen Algorithmus außerhalb dieser Liste signierte Tokens werden stets als nicht unterstützt gemeldet, statt als gültig markiert, was Sie auch vor dem klassischen alg=none-Fälschungstrick schützt.

Die häufigste Ursache ist das Einfügen von zusätzlichem Leerraum oder einem abschließenden Zeilenumbruch in das Geheimnis-Feld — der Prüfer hasht genau die Bytes, die Sie eingeben, sodass ein Kopier-Einfüge-Artefakt die Übereinstimmung zerstört. Vergewissern Sie sich außerdem, dass Sie das aktuelle Token prüfen: Wurde das JWT nach dem Kopieren neu ausgestellt, oder ist das Geheimnis des Anbieters base64-kodiert statt eine rohe Zeichenkette, dekodieren Sie es zuerst, bevor Sie es einfügen.

Klicke auf Try sample JWT, um ein Demo-HS256-Token mit den Claims sub, name, iat und exp zu laden, damit du siehst, wie Dekodierung und Ablaufprüfung funktionieren, bevor du dein eigenes Token einfügst. Sobald ein Token im Feld steht, erscheint daneben eine Clear-Schaltfläche, die die Eingabe mit einem Klick wieder leert.

Jedes der Panels Header, Payload und Signature hat in der oberen rechten Ecke einen eigenen Kopieren-Button, der nur das JSON dieses Abschnitts (oder die rohe Signaturzeichenkette) in die Zwischenablage kopiert. Unter den Panels gibt es außerdem einen primären Payload kopieren-Button für den häufigsten Fall, nur die Claims zu übernehmen, um sie in einen Debugger oder Fehlerbericht einzufügen.

Kopieren Sie den Wert nach 'Bearer ' im Authorization-Header — der Teil, der mit eyJ… beginnt, ist das eigentliche JWT — und fügen Sie ihn in den Decoder ein, um Header, Payload-Claims und Ablaufstatus sofort anzuzeigen. Wenn Sie die gesamte Zeichenfolge 'Bearer eyJ…' kopiert haben, entfernen Sie zuerst das Präfix 'Bearer ', damit das Token aus genau drei durch Punkte getrennten Teilen besteht.

Nein — das ist ein Decoder und Viewer, kein JWT-Editor. Eine Änderung der Payload würde die Signatur ungültig machen, sodass jeder Server, der das Token prüft, die manipulierte Version ablehnen würde. Um Claims zu ändern, musst du ein neues Token ausstellen, das mit dem richtigen Secret oder privaten Schlüssel signiert ist. Nutze den Decoder zum Lesen und Debuggen von Tokens, nicht zum Verändern.