JWT Decoder & Validator — lokal im Browser

Q: Was bedeuten die Standard-Claims?

iss ist der Aussteller, sub das Subjekt (meist der Nutzer), aud die vorgesehene Zielgruppe, iat der Ausstellungszeitpunkt, nbf der früheste Gültigkeitszeitpunkt und exp der Ablauf. Alle drei Zeiten sind Sekunden seit dem 1. Januar 1970 UTC.

Ein JSON Web Token besteht aus drei durch Punkte getrennten base64url-Teilen: einem Header, der sagt, wie signiert wurde, einer Payload mit Claims und einer Signatur über die ersten beiden. Die ersten beiden Teile sind lediglich kodiert, nicht verschlüsselt — wer das Token hat, kann sie lesen. Erst die Signatur verhindert, dass der Inhalt verändert wird.

Genau deshalb ist es eine schlechte Angewohnheit, ein aktives Token in eine beliebige Website einzufügen. Viele Tokens sind Bearer-Zugangsdaten: Wer eines besitzt, kann bis zum Ablauf als der darin genannte Nutzer handeln. Ein Decoder, der dein Token an einen Server schickt, gibt einen funktionierenden Schlüssel weiter. Dieser hier dekodiert in deinem Browser — und prüft die HMAC-Signatur ebenfalls dort, mit der browsereigenen WebCrypto-Implementierung.

So benutzt du das Tool

Füg das Token ein. Ein vorangestelltes Bearer wird automatisch entfernt, du kannst also direkt aus einem Authorization-Header kopieren.
Lies die Claim-Übersicht. Aussteller, Subjekt, Zielgruppe, Ausstellungs- und Ablaufzeit werden dekodiert und in deiner lokalen Zeitzone mit einer verständlichen Zeitangabe gezeigt.
Sieh dir die Ablaufzeile an. Ein abgelaufenes Token wird rot hervorgehoben — das erklärt die meisten unerwarteten 401-Antworten.
Bei einem HS256-, HS384- oder HS512-Token trägst du das gemeinsame Geheimnis ein und drückst auf Prüfen. Die Signatur wird lokal neu berechnet und verglichen.
Kopier die Payload, wenn du sie anderswo brauchst.

Beispiel aus der Praxis

Einen 401er debuggen

Eine API weist eine Anfrage ständig zurück. Du fügst das Token ein und die Claim-Übersicht zeigt, dass exp drei Stunden zurückliegt — das Token ist abgelaufen und der Client erneuert es nicht. Kein Serverumweg, kein Raten.

Ein Signaturgeheimnis bestätigen

Ein Staging-Dienst lehnt die Tokens deines Services ab. Du fügst ein Token ein, trägst das Geheimnis aus deiner Konfiguration ein, und die Signaturprüfung schlägt fehl — die beiden Umgebungen benutzen verschiedene Geheimnisse, und genau das ist der Bug.

Typische Anwendungsfälle

Herausfinden, warum eine API-Anfrage 401 oder 403 liefert
Prüfen, welche Claims dein Identitätsanbieter tatsächlich ausstellt
Bestätigen, dass zwei Umgebungen dasselbe Signaturgeheimnis nutzen
Die Ablaufzeit eines Tokens während eines Störfalls ablesen
Den Inhalt eines Tokens im Code-Review jemandem erklären
Ein Webhook prüfen, das mit einem symmetrischen Schlüssel signiert ist

Häufige Fehler

Dekodieren mit Prüfen verwechseln — Ein JWT kann jeder dekodieren. Erst die Signaturprüfung belegt, dass es nicht verändert wurde — prüf immer serverseitig, bevor du einem Claim vertraust.
alg: none akzeptieren — Ein Token mit none ist unsigniert. Ein Server, der diesen Header respektiert, nimmt beliebige Claims entgegen. Dieses Tool markiert das rot.
Geheimnisse in die Payload packen — Die Payload ist kodiert, nicht verschlüsselt. Alles, was du dort hineinschreibst, ist für jeden lesbar, der das Token hat.
Sekunden und Millisekunden verwechseln — exp, iat und nbf sind Sekunden seit der Epoche. Ein JavaScript-Millisekundenwert schiebt den Ablauf rund fünfzigtausend Jahre in die Zukunft.

Häufige Fragen

Wird mein Token irgendwohin geschickt?

Nein. Das Dekodieren ist base64url plus JSON-Parsing, und die HMAC-Prüfung nutzt das eingebaute WebCrypto deines Browsers. Beides passiert in der Seite. Es wird nichts übertragen — und das zählt, weil ein aktives Token meist ein funktionierender Zugang ist.

Warum kann ich ein RS256-Token nicht prüfen?

RS256 und ES256 nutzen asymmetrische Schlüssel: Zum Prüfen braucht man den öffentlichen Schlüssel des Ausstellers, üblicherweise von einem JWKS-Endpunkt. Da diese Seite keine Netzwerkanfragen stellt, kann sie diesen Schlüssel nicht holen. Symmetrische HMAC-Tokens lassen sich prüfen, weil du das Geheimnis selbst lieferst.

Was bedeuten die Standard-Claims?

iss ist der Aussteller, sub das Subjekt (meist der Nutzer), aud die vorgesehene Zielgruppe, iat der Ausstellungszeitpunkt, nbf der früheste Gültigkeitszeitpunkt und exp der Ablauf. Alle drei Zeiten sind Sekunden seit dem 1. Januar 1970 UTC.

Das Token dekodiert, aber die Signatur schlägt fehl — warum?

Meistens ist das Geheimnis falsch, hat ein Leerzeichen am Ende oder liegt in deiner Konfiguration base64-kodiert vor, während es hier roh benutzt wird. Es kann auch ein Algorithmus-Mismatch sein oder ein unterwegs verändertes Token — genau dafür ist die Signatur da.

Ist es sicher, ein Produktiv-Token hier einzufügen?

Es verlässt deinen Browser nicht, keine Anfrage trägt es also mit sich. Trotzdem ist es bei jedem Tool die sicherste Gewohnheit, nach Möglichkeit ein abgelaufenes oder Test-Token zu nehmen. Du kannst die Behauptung prüfen, indem du die Internetverbindung trennst und feststellst, dass die Seite weiterarbeitet.

Kann ich ein verschlüsseltes Token (JWE) dekodieren?

Nein. Hier geht es um signierte Tokens (JWS), und die benutzt praktisch jede API. Ein verschlüsseltes JWE-Token hat fünf statt drei Teile und braucht den Entschlüsselungsschlüssel.

Zuletzt aktualisiert 2026-09-15