JWT-Debugger / -Dekodierer

Fügen Sie ein beliebiges JWT ein, um seine drei durch Punkte getrennten Teile zu dekodieren — der base64url-kodierte Header, Payload und die Signatur werden als formatiertes JSON angezeigt, wobei die registrierten Claims (exp, iat, nbf und weitere) in Ihre Ortszeit umgerechnet werden. Anschließend können Sie die Signatur mit der WebCrypto-API prüfen: HMAC (HS256/384/512) mit einem Geheimnis oder RSA/ECDSA (RS256/384/512, ES256/384/512) mit einem PEM-Public-Key. Für Experimente steht ein Beispiel-Token HS256 mit einem Klick bereit. Alles läuft lokal — Token, Geheimnisse und Schlüssel werden nirgendwohin gesendet.
JWT-Token Format: header.payload.signature (drei base64url-Segmente).
Dekodiert
Header
Payload
Signatur (rohes base64url-Segment)
Warnung: Dieses Token deklariert alg:none, das bedeutet, dass es nicht signiert ist. Echte Dienste müssen unsignierte Token ablehnen — behandeln Sie es als nicht vertrauenswürdig.
Registrierte Claims
ClaimWertDeutung
Signatur prüfen
Geheimnis
crypto.subtle ist in diesem Kontext nicht verfügbar, daher ist die Signaturprüfung deaktiviert. Öffnen Sie die Seite über https: oder als lokale Datei, um sie zu aktivieren. Das Dekodieren funktioniert weiterhin.
So lesen Sie das Ergebnis: Der Header enthält meist alg (den Signaturalgorithmus) und typ. Die registrierten Claims, die mit Umrechnung in die Ortszeit angezeigt werden, sind iat (ausgestellt am), nbf (nicht gültig vor) und exp (Ablauf) — ein rotes Kennzeichen bedeutet, dass das Token abgelaufen ist, ein gelbes, dass es innerhalb von 24 Stunden abläuft. Die Signaturprüfung berechnet denselben MAC, den der Aussteller berechnen würde, bzw. prüft den RSA-/ECDSA-Public-Key, den Sie einfügen, und markiert das Token dann als GÜLTIG oder UNGÜLTIG. Nur Algorithmen, die die WebCrypto-Schicht des Browsers implementiert, können geprüft werden; alles andere wird als nicht unterstützt gemeldet und nicht geraten.

Gängige registrierte Claims: sub (Subjekt) ist der Benutzer oder die Entität, auf die sich das Token bezieht — in Ihrem Beispiel ist es nur eine numerische ID, doch Dienste tragen hier oft eine E-Mail-Adresse, einen Benutzernamen oder eine UUID ein. iss nennt den Aussteller, aud die vorgesehene Zielgruppe, und jti ist eine eindeutige Token-ID, die Wiederverwendung verhindert. Diese Claims sind nicht verschlüsselt; jeder, der das Token besitzt, kann sie lesen. Legen Sie daher niemals Passwörter oder Geheimnisse in den Payload eines JWT.

Datenschutz: Dekodierung und Prüfung finden vollständig auf dieser Seite mit der WebCrypto-API statt — das Token, Ihr Geheimnis und jeder öffentliche Schlüssel werden niemals übertragen. Bei einem Token mit alg:none zeigt die Seite eine deutliche Warnung: unsignierte Token sollte eine echte API niemals akzeptieren.