JWT-Decoder
JWT-Token einfügen und Header, Payload und Signatur dekodiert sehen — mit Claims-Erklärung und Ablauf-Prüfung.
Was ist ein JWT?
Ein JSON Web Token (JWT, ausgesprochen „dschott") ist eine kompakte, URL-sichere Möglichkeit, signiertes JSON zwischen Parteien zu übertragen – meistens zwischen einem Authentifizierungsserver und deiner App. Ein JWT besteht aus drei base64url-kodierten Teilen, die durch Punkte verbunden sind: header.payload.signature. Der Header gibt an, welcher Signaturalgorithmus verwendet wurde; der Payload ist ein JSON-Objekt mit Claims (Subjekt, Ablauf, eigene Daten); die Signatur ermöglicht dem Empfänger zu verifizieren, dass das Token nicht manipuliert wurde. Der Standard ist in RFC 7519 definiert.
So benutzt du diesen Decoder
Füge einen JWT in das Eingabefeld oben ein. Das Tool teilt an den Punkten, dekodiert die ersten beiden Segmente per base64url und gibt das resultierende JSON formatiert in zwei Panels aus – Header und Payload. Das dritte Panel zeigt die rohe Signatur-Zeichenkette. Enthält der Payload iat-, nbf- oder exp-Claims, zeigt das Tool diese auch als lesbare UTC-Zeitstempel und sagt dir, ob das Token abgelaufen ist. Die Dekodierung läuft live: Sobald du fertig getippt hast, aktualisieren sich die Panels.
Dekodiert ≠ verifiziert
Ein JWT-Decoder ist eine Debugging-Hilfe, kein Sicherheitstool. Jeder kann einen JWT dekodieren – die Kodierung ist von Natur aus umkehrbar. Erst die Signatur macht das Token vertrauenswürdig, und das Verifizieren einer Signatur erfordert das Geheimnis (HS256) oder den öffentlichen Schlüssel (RS256, ES256) des Ausstellers. Vertraue dem Inhalt eines JWT in Produktivcode niemals, ohne vorher die Signatur zu verifizieren. Verwende dafür die JWT-Bibliothek, die mit deinem Framework ausgeliefert wird; baue niemals selbst eine.
Standard-JWT-Claims
| Claim | Name | Bedeutung |
|---|---|---|
iss | Issuer (Aussteller) | Identifiziert die Instanz, die das Token ausgestellt hat (z. B. eine Auth-Server-URL). |
sub | Subject (Subjekt) | Identifiziert das Subjekt, um das es im Token geht – meist eine Benutzer-ID. |
aud | Audience (Empfänger) | Die vorgesehenen Empfänger des Tokens. Empfänger müssen Tokens ablehnen, die nicht an sie adressiert sind. |
exp | Ablaufzeitpunkt | Unix-Zeitstempel, nach dem das Token nicht mehr akzeptiert werden darf. |
nbf | Not before (Nicht vor) | Unix-Zeitstempel, vor dem das Token nicht akzeptiert werden darf. |
iat | Ausgestellt am | Unix-Zeitstempel, zu dem das Token ausgestellt wurde. |
jti | JWT-ID | Eindeutige Kennung für das Token, nützlich für Sperrlisten. |
Häufig gestellte Fragen
Wird mein JWT irgendwohin gesendet?
Warum verifiziert dieses Tool die Signatur nicht?
jwt, um Signaturen in einer kontrollierten Umgebung zu verifizieren.Ich erhalte „Kein JWT" – was ist falsch?
Bearer -Präfix (entferne es), nur der Payload wurde eingefügt (du brauchst auch Header und Signatur), oder das Token ist eigentlich ein JWE (verschlüsselt), das fünf Segmente hat und ohne den privaten Schlüssel des Empfängers nicht dekodierbar ist.Warum ist der Payload base64url und nicht reguläres base64?
+, / und = als Padding – nichts davon ist URL-sicher. Base64url ersetzt + durch -, / durch _ und lässt das Padding ganz weg. Das Ergebnis kann ohne weiteres Escaping in eine URL oder einen HTTP-Header eingebettet werden. Dieser Decoder konvertiert vor dem Aufruf des Browser-eigenen atob wieder zurück zu Standard-base64.Was bedeutet alg: none?
alg: none existiert in der Spezifikation, ist in der Praxis aber gefährlich: Eine berühmte Klasse von Schwachstellen nutzte Bibliotheken aus, die alg: none-Tokens akzeptierten, als wären sie signiert. Wenn du das in einem Produktionstoken siehst, behandle es als ernsten Fund.