JWT-Dekodierer

Dieser JWT Decoder zeigt Header und Payload eines JSON Web Tokens im Klartext an. Ein JWT ist standardmäßig nicht verschlüsselt: Seine Segmente sind lediglich Base64url-kodiert, jeder kann den Inhalt lesen. Wer ein aktives Token in ein fremdes Debug-Tool einfügt, gibt damit trotzdem sub, Rollen, scope und Ablaufzeit an einen Dritten weiter. Hier dekodiert ein nach WebAssembly kompiliertes Rust-Modul das Token direkt im Tab, kein Byte verlässt Ihr Gerät.

So dekodieren Sie ein JWT

1. Fügen Sie das Token in das Feld JWT Token ein. Leerzeichen und Zeilenumbrüche am Anfang und Ende werden entfernt.
2. Entfernen Sie ein Präfix wie Bearer aus einem kopierten Authorization-Header: Im Feld darf nur das Token stehen.
3. Klicken Sie auf Decode.
4. Lesen Sie die Bereiche Header und Payload, jeweils als eingerücktes JSON, und kopieren Sie sie über die jeweilige Schaltfläche.

Aufbau eines JWT: Header, Payload, Signatur

Ein JWT besteht aus drei Base64url-kodierten Segmenten, getrennt durch Punkte: header.payload.signature. Der Header nennt den Signaturalgorithmus (HS256, RS256, ES256 und andere) und den Tokentyp. Die Payload enthält die Claims, also die eigentlichen Daten: registrierte Claims wie iss (Aussteller), sub (Subjekt), aud (Zielgruppe), exp (Ablauf) und iat (Ausstellungszeit) sowie eigene Claims Ihrer Anwendung. Die Signatur wird über die ersten beiden Segmente berechnet und belegt, dass das Token nicht verändert wurde.

Die wichtigsten Claims lesen

• exp, iat, nbf: Ablauf, Ausstellung und „nicht vor“. Es sind Unix-Zeitstempel in Sekunden, die als Zahl angezeigt werden. Mit dem Unix-Zeitstempel-Konverter sehen Sie das Datum und erkennen, ob das Token abgelaufen ist.
• iss und aud: wer das Token ausgestellt hat und für welche API es gedacht ist. Eine Abweichung ist eine häufige Ursache für 401-Antworten.
• sub: das Subjekt, meist die Benutzer- oder Client-ID.
• scope, roles, Mandanten-IDs: eigene oder anbieterspezifische Claims (Keycloak, Auth0, Entra ID), die die Berechtigungen steuern.
• alg und kid im Header: Algorithmus und Schlüssel-ID, mit der der Prüfschlüssel aus einem JWKS gewählt wird.

Dekodieren ist nicht Verifizieren

Das ist der entscheidende Punkt. Dekodieren wandelt Base64url in lesbares JSON um, das kann jeder. Verifizieren ist ein eigener kryptografischer Schritt, der die Signatur mit einem Geheimnis oder öffentlichen Schlüssel prüft und so bestätigt, dass das Token echt und unverändert ist. Dieses Tool dekodiert nur, das Signatursegment wird ignoriert. Vertrauen Sie einer dekodierten Payload in Produktion nie als Identitätsnachweis; die Prüfung gehört auf den Server, mit dem richtigen Schlüssel.

Fehler und Sonderfälle

• Nicht drei Segmente: Das Token muss genau zwei Punkte enthalten. Verschlüsselte Tokens (JWE) haben fünf Segmente und sind ohne Schlüssel nicht lesbar; sie werden mit expected 3 parts separated by dots abgelehnt.
• Ungültige Kodierung: Die Segmente müssen Base64url ohne =-Auffüllung sein, wie es die Spezifikation verlangt. Ein Fremdzeichen, etwa das Leerzeichen in Bearer eyJ…, löst einen Kodierungsfehler aus.
• Kein JSON: Header und Payload müssen beide gültige JSON-Objekte ergeben.
• Signatur: Ihr Inhalt wird nicht ausgewertet. Ein unsigniertes Token mit leerer Signatur (header.payload.) wird trotzdem dekodiert.

Typische Anwendungsfälle

• Auth-Probleme debuggen: herausfinden, warum eine Anfrage abgelehnt wird, über exp (abgelaufen?) oder aud (falsche Zielgruppe?).
• Eigene Claims prüfen: kontrollieren, ob Rollen, Scopes oder Mandanten-ID beim Login korrekt gesetzt wurden.
• Identitätsanbieter verstehen: die Tokenstruktur vor einer OpenID-Connect-Integration ansehen.

Im Vergleich zur Kommandozeile

Im Terminal lässt sich eine Payload dekodieren, indem man an den Punkten trennt und das mittlere Segment Base64-dekodiert. Base64url nutzt aber - und _ und lässt die Auffüllung weg, daher scheitert ein einfaches base64 -d oft, bis man Zeichen ersetzt und = ergänzt. Diese Seite übernimmt das und formatiert das JSON.

Datenschutz: Das Token bleibt im Tab

Ein Access Token ist ein Zugangsnachweis: Solange es nicht abgelaufen ist, kann es gegen Ihre API wiederverwendet werden. Ein externer Decoder setzt es Protokollierung und Abfangen aus, und die Claims enthalten oft personenbezogene Daten (E-Mail, Name, Kennung), die unter die DSGVO fallen. Hier wird das JWT vollständig clientseitig dekodiert: nichts wird hochgeladen, übertragen oder gespeichert. Schließen Sie den Tab, und das Token ist weg.

Häufige Fragen

Prüft das Tool die Signatur des JWT?

Nein. Es dekodiert nur Header und Payload. Die Prüfung erfordert das Geheimnis oder den öffentlichen Schlüssel und gehört in Ihren Server oder eine JWT-Bibliothek.

Darf ich ein Produktions-Token einfügen?

Das Token wird nirgendwohin gesendet, die Dekodierung läuft im Browser. Behandeln Sie ein gültiges Token trotzdem wie ein Passwort und lassen Sie es nicht im Zwischenablageverlauf oder in geteilten Bildschirmen liegen.

Was bedeutet „expected 3 parts separated by dots“?

Die Eingabe ist kein signiertes JWT: Sie ist abgeschnitten, hat ein Präfix, ist ein opakes Access Token ohne JWT-Format oder ein verschlüsseltes JWE mit fünf Segmenten.

Wie erkenne ich, ob das Token abgelaufen ist?

Lesen Sie den Claim exp in der Payload und wandeln Sie die Unix-Sekunden mit dem Zeitstempel-Konverter in ein Datum um. Liegt es in der Vergangenheit, ist das Token abgelaufen.

Kann das Tool ein verschlüsseltes JWT (JWE) dekodieren?

Nein. Die Payload eines JWE ist verschlüsselt und ohne Schlüssel nicht lesbar.

Kann ich Claims ändern und das Token neu signieren?

Nein. Das Tool arbeitet nur lesend und erstellt oder signiert keine Tokens.

Verwandte Werkzeuge: Die JWT-Segmente sind Base64url-kodiert, der Base64-Encoder und -Decoder hilft daher bei Rohwerten, und der JSON-Formatierer bringt umfangreiche Payloads in Form.