JWT-Decoder – JSON Web Tokens dekodieren und prüfen
Fügen Sie einen JSON Web Token ein, um Header und Payload als formatiertes JSON zu sehen, Ausstellungs- und Ablaufzeit zu prüfen und optional eine HMAC-Signatur mit Ihrem Secret zu verifizieren.
Ein JWT besteht aus drei Base64URL-Teilen, getrennt durch Punkte: Header.Payload.Signatur. Nach dem Einfügen sehen Sie Header (Algorithmus) und Payload (Claims wie sub, iat und exp) sowie, ob der Token abgelaufen ist. Dekodieren beweist keine Echtheit – mit dem Secret prüfen Sie HS256, HS384 oder HS512.
So funktioniert: JWT-Decoder
- Token einfügen (mit oder ohne „Bearer “).
- Status ablesen: abgelaufen oder nicht.
- Header- und Payload-JSON prüfen.
- Optional das Secret zur Prüfung der HMAC-Signatur eingeben.
- Header oder Payload bei Bedarf kopieren.
Aufbau eines JWT
Ein JSON Web Token besteht aus drei Base64URL-kodierten Textteilen, verbunden durch Punkte:
Header.Payload.Signatur
- Der Header nennt den Signaturalgorithmus, etwa HS256 oder RS256.
- Die Payload enthält die Claims: wen der Token betrifft, wann er ausgestellt wurde und wann er abläuft.
- Die Signatur beweist, dass Header und Payload von jemandem mit dem Schlüssel stammen und unverändert sind.
Base64URL ist eine Kodierung, keine Verschlüsselung. Jeder mit dem Token kann die Payload lesen – Passwörter oder Geheimnisse gehören deshalb nie in einen JWT.
Standard-Claims
| Claim | Bedeutung |
|---|---|
| iss | Aussteller |
| sub | Subjekt, meist die Benutzer-ID |
| aud | Empfänger des Tokens |
| exp | Ablaufzeit (Unix-Zeitstempel) |
| nbf | Nicht gültig vor |
| iat | Ausstellungszeit |
| jti | Eindeutige Token-ID |
Zeiten sind Unix-Zeitstempel in Sekunden; der Decoder zeigt sie als lokales Datum. Andere Zeitstempel rechnet der Unix-Zeitstempel umrechnen um.
Dekodieren ist nicht Prüfen
Das Lesen eines Tokens zeigt nur, was er behauptet. Ein Server muss vor jeder Verwendung die Signatur prüfen. Bei HMAC-Verfahren (HS256, HS384, HS512) können Sie hier das gemeinsame Secret eingeben. RS256- und ES256-Tokens nutzen Public-Key-Signaturen und brauchen den öffentlichen Schlüssel des Ausstellers, den dieses Tool nicht prüft.
Häufige Probleme
- „Abgelaufen“: exp liegt in der Vergangenheit; neuen Token anfordern oder Serveruhr prüfen.
- Ungültiges Format: Token beim Kopieren abgeschnitten oder mit Anführungszeichen.
- Signatur passt nicht: falsches Secret, andere Umgebung (Test oder Produktion) oder veränderter Token.
Datenschutz
Tokens gewähren oft Zugriff auf Konten. Dieser Decoder arbeitet vollständig im Browser und sendet nichts. Behandeln Sie echte Tokens trotzdem wie Passwörter. Verwandt: Base64 kodieren / dekodieren und JSON formatieren.
Speichern Sie Tokens im Frontend möglichst nicht dauerhaft im Local Storage, sondern nutzen Sie sichere, kurzlebige Tokens.
Ein typischer Debug-Fall aus dem Entwickleralltag: Nach dem Login mit Keycloak schlägt jede API-Anfrage mit 401 fehl. Der Entwickler fügt den Access Token in den JWT-Decoder von Toolinga ein und sieht sofort zwei Probleme: Der Claim „aud“ enthält die falsche Client-ID, und „exp“ liegt nur 60 Sekunden in der Zukunft – der Token läuft ab, bevor die App ihn überhaupt nutzt. Zwei Minuten Analyse statt stundenlangem Rätselraten im Code, und der Fehler ist gefunden.
Häufig geht es auch um Berechtigungen: Viele APIs steuern den Zugriff über Claims wie „roles“ oder „groups“ in der Payload. Fehlt dem Nutzer die Rolle „admin“, blockt das Backend jede Anfrage. Im Decoder sehen Sie auf einen Blick, welche Rollen der Token tatsächlich enthält – und erkennen sofort, ob das Problem beim Token (falsche Rollen) oder bei der API-Logik (falsche Prüfung) liegt.
Diese kostenlosen Tools könnten dir auch helfen: JSON formatieren, Passwort-Generator und Regex-Tester.
Häufige Fragen
Wie dekodiere ich einen JWT?
Token einfügen – Header und Payload werden aus Base64URL dekodiert und als JSON angezeigt.
Ist das Dekodieren online sicher?
Dieses Tool arbeitet lokal im Browser. Die Payload ist nicht geheim, der Token kann aber Zugriff gewähren.
Woran erkenne ich, ob ein JWT abgelaufen ist?
Am Claim exp. Der Decoder zeigt ihn als Datum und meldet, ob er vorbei ist.
Kann ich die Signatur prüfen?
Ja, für HS256, HS384 und HS512 mit dem Secret. RS- und ES-Tokens brauchen den öffentlichen Schlüssel.
Ist ein JWT verschlüsselt?
Normalerweise nicht. Standard-JWTs (JWS) sind nur signiert.
Warum wird mein JWT als ungültig abgelehnt?
Die häufigsten Ursachen: Der Token ist abgelaufen (exp liegt in der Vergangenheit), die Signatur stimmt nicht (falsches Secret oder falsche Umgebung, etwa Test statt Produktion), oder das Format ist beschädigt – zum Beispiel durch abgeschnittenes Kopieren oder mitkopierte Anführungszeichen. Prüfen Sie im Decoder zuerst exp und iat als Datum und dann, ob alle drei Token-Teile vorhanden sind.
Was ist der Unterschied zwischen JWT und JWE?
Ein normales JWT (genau genommen JWS) ist nur signiert, aber für jeden lesbar – jeder kann die Payload dekodieren. JWE steht für „JSON Web Encryption“ und verschlüsselt die Payload tatsächlich, sodass nur der Schlüsselinhaber sie lesen kann. Für die meisten Login-Szenarien reicht ein signiertes JWT völlig aus; sensible Daten gehören aber in ein JWE – oder gar nicht erst in den Token.
Wie lange sollte ein JWT gültig sein?
So kurz wie praktikabel: Access Tokens typischerweise 5 bis 60 Minuten, Refresh Tokens Stunden bis Tage. Kurze Laufzeiten begrenzen den Schaden erheblich, falls ein Token gestohlen wird. Läuft Ihr Token nach wenigen Minuten ab und die App erneuert ihn nicht automatisch, liegt das Problem meist beim Refresh-Flow – nicht beim Token selbst.
Zuletzt aktualisiert: