JWT-Decoder – JSON Web Tokens online dekodieren

So nutzen Sie den JWT-Decoder

Fügen Sie ein JSON Web Token ein, die lange Zeichenkette, die meist auf Authorization: Bearer folgt.
Header und Payload werden dekodiert und als formatiertes JSON angezeigt.
Zeit-Claims wie exp, iat und nbf werden in lesbare Datumsangaben umgewandelt, sodass Sie auf einen Blick sehen, ob das Token abgelaufen ist.

Datenschutz: Fügen Sie Produktions-Tokens nie auf einer Website ein, der Sie nicht vertrauen; ein gültiges Token kann von jedem, der es sieht, bis zu seinem Ablauf wiederverwendet werden. Dieser Decoder läuft vollständig in Ihrem Browser: Das Token wird nie hochgeladen, protokolliert oder gespeichert. Verwenden Sie trotzdem lieber Test-Tokens, und widerrufen Sie jedes Token, bei dem Sie vermuten, dass es offengelegt wurde.

Aufbau eines JWT

Ein JSON Web Token, spezifiziert in RFC 7519, ist ein kompaktes Format, um Claims zwischen Parteien zu übertragen. Die übliche signierte Form (JWS) besteht aus drei durch Punkte getrennten Teilen:

header.payload.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.<signature>

Header: JSON, das das Token beschreibt, vor allem den Signaturalgorithmus. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 wird zu {"alg":"HS256","typ":"JWT"} dekodiert.
Payload: JSON mit den Claims, also den Aussagen über den Benutzer oder die Sitzung.
Signatur: wird über den kodierten Header und die Payload berechnet, mit einem Geheimnis (HMAC, z. B. HS256) oder einem privaten Schlüssel (z. B. RS256, ES256).

Jeder Teil ist mit base64url kodiert, dem URL-sicheren Base64-Alphabet ohne Auffüllzeichen. Deshalb enthalten Tokens - und _, und deshalb beginnen JWTs fast immer mit eyJ: So wird das öffnende {" eines JSON-Objekts kodiert, wenn ein typischer kleingeschriebener Schlüsselname folgt. Die Kodierung selbst können Sie mit dem Base64-Encoder ausprobieren.

Registrierte Claims

Claim	Name	Bedeutung
`iss`	Issuer (Aussteller)	Wer das Token erstellt und signiert hat.
`sub`	Subject (Subjekt)	Wen das Token betrifft, meist eine Benutzer-ID.
`aud`	Audience (Zielgruppe)	Für welche(n) Dienst(e) das Token bestimmt ist.
`exp`	Expiration time (Ablaufzeit)	Unix-Zeitstempel, nach dem das Token abgelehnt werden muss.
`nbf`	Not before (nicht vor)	Unix-Zeitstempel, vor dem das Token noch nicht gültig ist.
`iat`	Issued at (ausgestellt am)	Unix-Zeitstempel, zu dem das Token erstellt wurde.
`jti`	JWT ID	Eindeutige Kennung, nützlich gegen Replay-Angriffe.

Alle diese Claims sind in RFC 7519 optional; die Anwendungen entscheiden, welche sie verlangen. Zeit-Claims sind in Sekunden angegeben, nicht in Millisekunden; der Unix-Zeitstempel-Konverter erklärt den Unterschied.

Häufige Fehler

Dekodieren ist nicht Verifizieren

Jeder kann ein JWT dekodieren; genau das macht dieses Tool. Das Dekodieren zeigt Ihnen, was ein Token behauptet, nicht, ob diese Behauptungen echt sind. Ein Server muss mit dem richtigen Schlüssel die Signatur verifizieren und exp, nbf, iss und aud prüfen, bevor er irgendeiner Angabe in der Payload vertraut.

Die Payload ist nicht geheim

Ein signiertes JWT kann jeder lesen, der es besitzt. Legen Sie keine Passwörter, keine personenbezogenen Daten, die der Client nicht sehen soll, und keine internen Geheimnisse in die Payload. Wenn der Inhalt vertraulich sein muss, verwenden Sie ein verschlüsseltes JWT (JWE) oder behalten Sie die Daten auf dem Server.

alg: none und Algorithmusverwechslung

Die JOSE-Spezifikationen definieren einen Wert "alg": "none" für ungesicherte Tokens mit leerer Signatur. Eine Bibliothek, die sich nach dem Header des Tokens selbst richtet, könnte ein gefälschtes Token wie dieses akzeptieren:

{"alg": "none", "typ": "JWT"}
{"sub": "admin"}
(empty signature)

Ein verwandter Angriff stellt ein RS256-Token auf HS256 um, sodass der öffentliche Schlüssel als HMAC-Geheimnis missbraucht wird. Die Abwehr ist in beiden Fällen dieselbe: Legen Sie die erlaubten Algorithmen auf dem Server fest und lassen Sie nie das Token entscheiden.

Tipps

Halten Sie Access-Tokens kurzlebig und verwenden Sie Refresh-Tokens für längere Sitzungen.
Erlauben Sie beim Prüfen von exp und nbf über mehrere Server hinweg eine kleine Zeitabweichung (Clock Skew, zum Beispiel eine Minute).
Verwenden Sie eine gut gepflegte JWT-Bibliothek, statt Tokens von Hand zu parsen und zu verifizieren.

Häufig gestellte Fragen

Kann dieses Tool eine JWT-Signatur verifizieren?

Für die Verifizierung braucht man das Geheimnis oder den öffentlichen Schlüssel des Ausstellers, und sie muss in Ihrem Backend stattfinden. Dieses Tool dient dazu, beim Debuggen den Header und die Claims eines Tokens zu untersuchen.

Warum wird mein Token als abgelaufen angezeigt?

Der Claim exp liegt vor der aktuellen Uhrzeit auf Ihrem Gerät. Prüfen Sie, ob Ihre Uhr richtig geht und ob der Aussteller exp in Sekunden angegeben hat.

Sind JWTs verschlüsselt?

Signierte JWTs (JWS), die weitaus meisten im Einsatz, sind nur kodiert und signiert, sodass jeder sie lesen kann. Verschlüsselte JWTs (JWE) haben fünf statt drei Teile.

Ist es sicher, mein Token hier einzufügen?

Das Dekodieren geschieht lokal, und es wird nichts übertragen. Als allgemeine Regel gilt: Fügen Sie aktive Produktions-Tokens nicht in Online-Tools ein, die Sie nicht geprüft haben.

Aktualisiert 2026-10-17