JWT Decoder

So verwendest du den JWT-Dekoder

1. Füge dein Token in den großen Eingabebereich ein. Ein JWT ist drei Base64URL-kodierte Segmente, die durch Punkte verbunden sind, typischerweise beginnend mit eyJ, weil das die Base64URL-Kodierung von {" ist.
2. Klicke auf "Dekodieren" (oder warte auf das automatische Dekodieren beim Einfügen). Das Panel teilt sich in drei Spalten auf: Header, Payload und Signatur.
3. Lies den Header, um den Signierungsalgorithmus (alg) und den Token-Typ (typ) zu sehen. Alles außer none bedeutet, dass eine Signatur vorhanden ist.
4. Inspiziere den Payload, um jeden Claim zu lesen. Registrierte Claims (iss, sub, aud, exp, nbf, iat, jti) erhalten freundliche Beschriftungen, und Zeitstempel-Claims werden von Unix-Sekunden in dein lokales Datum und Uhrzeit umgewandelt.
5. Überprüfe das Ablaufzeit-Badge neben exp, um zu sehen, ob das Token noch gültig ist, wie lange es abläuft oder wie lange es abgelaufen ist.
6. Kopiere ein beliebiges Segment mit den Kopier-Schaltflächen neben jedem Panel, damit du dekodiertes JSON in Postman, curl oder deine IDE einfügen kannst.

Was dieses Tool macht und wie es funktioniert

Der Dekoder teilt das Token auf den zwei Punkt-Trennzeichen in seine drei Segmente auf, dann läuft jedes durch einen Base64URL-Dekoder, der - und _ zurück zu Standard + und / substituiert, auf ein Vielfaches von vier neu auffüllt und atob plus einen UTF-8-TextDecoder verwendet, um JSON-Text zu erzeugen. JSON.parse wandelt das in ein Objekt um, das Preact als hübsch gedruckten Baum rendert. Das Signatur-Segment wird als rohes Base64URL belassen, weil seine Verifizierung den Servergeheimnis (für HMAC) oder den öffentlichen Schlüssel (für RSA oder ECDSA) erfordern würde, und das Offenlegen dieser im Browser besiegt den Sinn des Signierens. Die gesamte Pipeline ist reines JavaScript: kein fetch, kein XHR, kein Service Worker. Dein Token überschreitet niemals die Tab-Grenze.

Wann du dies verwenden würdest

• Debuggen einer 401-Antwort von deiner API und Prüfen, ob der aud-Claim tatsächlich der erwarteten Zielgruppe entspricht.
• Überprüfen, dass ein neu geprägtes Zugriffs-Token die Rollen oder Bereiche trägt, nach denen deine Autorisierungs-Middleware sucht.
• Bestätigen, dass dein Identitätsanbieter benutzerdefinierte Claims unter dem Namespace kodiert, den du in Auth0, Okta, Keycloak oder Cognito konfiguriert hast.
• Den exp-Claim lesen, um zu bestätigen, dass ein kurzlebiges Token wirklich kurzlebig ist, bevor du es in die Produktion auslieferst.
• Einem Teamkollegen beibringen, warum das Speichern von PII im Payload eine schlechte Idee ist - der Payload ist signiert, nicht verschlüsselt, und jeder mit dem Token kann ihn lesen.
• Die Claims in einem funktionierenden Token mit einem defekten vergleichen, wenn du mit einem neuen Partner integrierst.

Häufige Fallstricke und Randfälle

• JWT mit JWE verwechseln. Ein fünfsegmentiges Token (vier Punkte) ist ein verschlüsseltes JWE und kann ohne den Entschlüsselungsschlüssel nicht gelesen werden. Dieser Dekoder behandelt nur dreisegmentige JWS.
• Padding-Fehler beim Kopieren. Einige Logger kürzen die Signatur. Der Header und Payload dekodieren noch, aber dein nachgelagerter Prüfer lehnt das Token ab.
• Takt-Versatz. Ein Token, das um eine Sekunde abgelaufen aussieht, kann noch vom Server akzeptiert werden dank eines Toleranzfensters (normalerweise 30-60 Sekunden). Die Benutzeroberfläche zeigt deine Lokalzeit, die vom Uhrzeitstempel des Ausstellers abweichen kann.
• Verschachteltes JSON in Claims. Einige IdPs serialisieren Rollen als JSON-String innerhalb eines Claims statt als Array. Der Dekoder zeigt den rohen String - parse ihn ein zweites Mal, um das Array zu inspizieren.
• UTF-8 im Payload. Claims mit Nicht-ASCII-Text (Namen, Beschriftungen in anderen Schriften) verlassen sich auf korrektes UTF-8-Dekodieren. Das Tool verwendet TextDecoder("utf-8"), sodass Multi-Byte-Sequenzen und Surrogatpaare den Roundtrip überleben.

JWT-Format auf einen Blick

JSON Web Token sind durch RFC 7519 definiert, das auf JWS (RFC 7515) für Signierung und JWA (RFC 7518) für Algorithmus-Bezeichner aufbaut. Eine JWS-kompakte Serialisierung ist BASE64URL(header) "." BASE64URL(payload) "." BASE64URL(signature). Das Header-Objekt muss alg (den Signierungsalgorithmus wie HS256, RS256, ES256 oder EdDSA) enthalten und enthält normalerweise typ: "JWT". Der Payload ist ein Satz von Claims. Sieben Namen sind in RFC 7519 selbst registriert; öffentliche Claims leben im IANA-JSON-Web-Token-Claims-Register; private Claims sind, was deine Anwendung erfindet. Wichtig ist, dass ein JWT signiert, nicht verschlüsselt ist - alles außer der Signatur ist im Klartext, und jeder kann es Base64URL-dekodieren. Behandle JWTs als Bearer-Token: Besitz ist Autorisierung.

Vergleich zu Alternativen

Auf der Kommandozeile kannst du dasselbe Dekodieren mit cut -d. -f2 <<< "$TOKEN" | base64 -d | jq erreichen, aber das ist umständlich mit Base64URL-Padding und zeigt keinen Ablaufstatus an. Dedizierte CLIs wie jwt-cli (cargo install jwt-cli) und step jwt inspect von Smallstep sind ausgezeichnet, wenn du bereits ein Terminal offen hast. IDE-Plugins wie die JWT-Erweiterung für VS Code dekodieren Token inline in deinem Editor. Browser-Erweiterungen existieren, lesen aber typischerweise Seiteninhalte - ein echtes Risiko, wenn du Arbeits-Token in localStorage hast. Für die Verifizierung von Signaturen benötigst du noch ein Backend oder eine Bibliothek wie jose, pyjwt oder jsonwebtoken, weil nur sie den Schlüssel haben. Verwende diese Seite, wenn du eine schnelle schreibgeschützte Inspektion ohne Installation von etwas benötigst.