Werkzeuge
Blog Home

Kostenloser Online JWT Decoder

Dekodieren und inspizieren Sie JSON Web Tokens direkt in Ihrem Browser. Zeigen Sie Header, Payload und Claims mit lesbaren Ablaufdaten an. Es wird nie etwas an einen Server gesendet.

Token-Inspektor

Algorithmus
—
Typ
—
Ablauf
—

Header

Payload

Signatur

Die Signaturprüfung erfordert den geheimen Schlüssel und wird von diesem Tool nicht unterstützt.
Die gesamte Dekodierung erfolgt lokal in Ihrem Browser. Ihr Token wird nie hochgeladen, gespeichert oder protokolliert.

Was ist ein JWT?

Ein JSON Web Token (JWT, RFC 7519) ist eine kompakte, URL-sichere Möglichkeit, Claims zwischen zwei Parteien darzustellen. Es besteht aus drei Base64URL-kodierten Teilen, die durch Punkte verbunden sind — header.payload.signature. Der häufigste Anwendungsfall ist die zustandslose Authentifizierung von REST-APIs: Nach der Anmeldung stellt der Server ein signiertes Token aus, das der Client bei jeder Anfrage mitsendet, sodass der Server die Identität ohne Sitzungsstatus überprüfen kann.

JWT-Struktur: Header, Payload, Signatur

Header

Deklariert den Signaturalgorithmus (alg, z. B. HS256, RS256, ES256) und den Token-Typ (typ), fast immer JWT.

Payload

Enthält die Standard- und benutzerdefinierten Claims. Es ist nur Base64URL-kodiert, nicht verschlüsselt — jeder kann es lesen, speichern Sie also niemals Geheimnisse darin.

Signatur

Wird berechnet, indem der kodierte Header und das Payload mit einem geheimen oder privaten Schlüssel signiert werden. Sie belegt die Integrität, kann aber ohne diesen Schlüssel nicht überprüft werden.

Häufige JWT-Claims erklärt

Das Payload enthält Claims — Aussagen über das Token. Diese registrierten Claims sind im JWT-Standard definiert:

sub Subject — das Subjekt, auf das sich das Token bezieht, meist die Benutzer-ID.
iss Issuer — gibt an, wer das Token ausgestellt hat.
aud Audience — die Empfänger, für die das Token bestimmt ist.
exp Expiration Time — Unix-Zeitstempel, nach dem das Token abgelehnt werden muss.
iat Issued At — Unix-Zeitstempel der Token-Erstellung.
nbf Not Before — Unix-Zeitstempel, vor dem das Token nicht akzeptiert werden darf.
jti JWT ID — eine eindeutige Kennung, nützlich zum Verhindern von Token-Replay.

JWT-Sicherheits-Best-Practices

Speichern Sie niemals sensible Daten im Payload — es ist nur kodiert, nicht verschlüsselt, und für jeden lesbar.
Setzen Sie immer einen exp-Claim und halten Sie die Token-Lebensdauer kurz, um die Auswirkungen eines geleakten Tokens zu begrenzen.
Bevorzugen Sie asymmetrische Algorithmen (RS256 oder ES256) für Microservices, damit Dienste ohne gemeinsames Geheimnis verifizieren können.
Validieren Sie immer die Claims iss und aud serverseitig und lehnen Sie Tokens ab, deren alg auf none gesetzt ist.
Geben Sie Tokens niemals in URLs oder Logdateien preis; senden Sie sie im Authorization-Header und speichern Sie sie sicher.

Häufig gestellte Fragen

Nein. Ein Standard-JWT ist signiert, nicht verschlüsselt. Header und Payload sind nur Base64URL-kodiert, das heißt, jeder, der das Token besitzt, kann dessen Inhalt dekodieren und lesen. Die Signatur garantiert nur, dass das Token nicht manipuliert wurde — sie verbirgt die Daten nicht. Wenn Sie Vertraulichkeit benötigen, verwenden Sie JWE (JSON Web Encryption) oder speichern Sie niemals sensible Daten im Payload.

Nein. Die Überprüfung einer JWT-Signatur erfordert den geheimen Schlüssel (bei HS256) oder den öffentlichen Schlüssel (bei RS256/ES256), den nur der ausstellende Server besitzen sollte. Dieses Tool dekodiert das Token bewusst clientseitig ohne Überprüfung, sodass kein Schlüssel jemals Ihr Gerät verlässt. Überprüfen Sie Signaturen immer auf Ihrem Server, niemals im Browser.

HS256 ist symmetrisch: Derselbe geheime Schlüssel signiert und überprüft das Token, sodass jede Partei, die überprüfen kann, auch Tokens fälschen kann. RS256 ist asymmetrisch: Ein privater Schlüssel signiert und ein separater öffentlicher Schlüssel überprüft. RS256 wird für verteilte Systeme und Microservices bevorzugt, da Sie den öffentlichen Schlüssel frei teilen und den privaten Signaturschlüssel geheim halten können.

Der exp-Claim ist ein Unix-Zeitstempel in Sekunden. Ein häufiger Fehler ist, ihn in Millisekunden (13 Stellen) statt in Sekunden (10 Stellen) anzugeben, wodurch das Ablaufdatum weit in der Vergangenheit oder Zukunft liegt. Auch eine Zeitabweichung zwischen Servern kann zu vorzeitigem Ablauf führen — gewähren Sie bei der Validierung einen kleinen Spielraum. Verwenden Sie den Token-Inspektor oben, um das lesbare Ablaufdatum neben dem Rohwert zu sehen.