Dieses Werkzeug dekodiert nur Header und Payload eines JWT — es prüft die Signatur nicht. Ein dekodiertes Token kann trotzdem abgelaufen, manipuliert oder ungültig sein. Vertrauen Sie JWT-Inhalten nie ohne serverseitige Prüfung.
100% lokale Verarbeitung — das Token wird vollständig in Ihrem Browser dekodiert und niemals irgendwohin gesendet.
Ausgestellt am (iat)-
Läuft ab am (exp)-
Über JWT (JSON Web Token)
Ein JWT ist ein kompaktes, URL-sicheres Token aus drei durch Punkte getrennten, base64url-kodierten Teilen: ein Header, der den Signaturalgorithmus beschreibt, ein Payload mit Claims (Daten) und eine Signatur, die prüft, ob das Token verändert wurde. Dieses Werkzeug dekodiert Header und Payload zurück in lesbares JSON.
Da Header und Payload nur base64url-kodiert und nicht verschlüsselt sind, kann jeder sie ohne geheimen Schlüssel dekodieren und lesen — das ist beabsichtigt. Die Signatur eines JWT schützt vor Manipulation, nicht davor, dass der Inhalt lesbar ist, weshalb ein reiner Decoder niemals bestätigen kann, dass ein Token wirklich gültig ist.
Wie dekodiere ich ein JWT, und was bedeuten exp/iat?
Ein JWT (JSON Web Token) besteht aus drei durch Punkte verbundenen, base64url-kodierten Teilen: header.payload.signature. Zum Lesen teilen Sie den String an den Punkten, dekodieren Header und Payload mit base64url und parsen jeden Teil als JSON — zum Dekodieren wird kein geheimer Schlüssel benötigt, nur zur Überprüfung der Signatur. Die Payload-Claims iat (Ausstellungszeitpunkt) und exp (Ablaufzeitpunkt) sind Unix-Zeitstempel (Sekunden seit dem 1.1.1970), die dieses Werkzeug in ein lesbares Datum umwandelt.
Schritte zum Dekodieren eines JWT
- Fügen Sie den vollständigen JWT-String (alle drei durch Punkte getrennten Teile) in das Eingabefeld ein.
- Das Werkzeug teilt das Token an seinen Punkten und dekodiert den ersten Teil (Header) und den zweiten Teil (Payload) mit base64url.
- Jeder dekodierte Teil wird als JSON geparst und zur besseren Lesbarkeit formatiert.
- Enthält die Payload iat- oder exp-Claims, werden diese von Unix-Zeitstempeln in ein lesbares lokales Datum und eine Uhrzeit umgewandelt.
- Der dritte Teil (Signatur) bleibt unverändert und wird nie dekodiert oder geprüft, da die Überprüfung den geheimen oder öffentlichen Schlüssel des Ausstellers erfordert, über den dieses Werkzeug nicht verfügt.
JWT-Struktur und Zeitstempel-Umrechnung
JWT = base64url(Header) + "." + base64url(Payload) + "." + Signatur · Lesbares Datum = new Date(exp_oder_iat_Sekunden × 1000)
- iat (issued at) = der Unix-Zeitstempel in Sekunden, wann das Token erstellt wurde
- exp (expiration) = der Unix-Zeitstempel in Sekunden, ab dem das Token als abgelaufen gelten sollte
- base64url = eine URL-sichere Variante der base64-Kodierung, die + und / durch - und _ ersetzt und auf Padding verzichtet
Gängige JWT-Payload-Claims
| Claim | Bedeutung |
|---|
| iss | Issuer — wer das Token erstellt und signiert hat |
| sub | Subject — die Identität, auf die sich das Token bezieht, etwa eine Benutzer-ID |
| aud | Audience — der vorgesehene Empfänger des Tokens |
| iat | Issued at — wann das Token erstellt wurde (Unix-Zeitstempel) |
| exp | Expiration — wann das Token seine Gültigkeit verliert (Unix-Zeitstempel) |
Häufig gestellte Fragen
Beweist das Dekodieren eines JWT, dass es gültig oder vertrauenswürdig ist?
Nein. Das Dekodieren zeigt nur, was in Header und Payload steht; es sagt nichts darüber aus, ob die Signatur echt ist, ob das Token von einer vertrauenswürdigen Quelle ausgestellt wurde oder ob es manipuliert wurde. Nur die Überprüfung der Signatur mit dem korrekten geheimen oder öffentlichen Schlüssel kann die Echtheit eines Tokens bestätigen.
Warum kann jeder die Payload meines JWT ohne Passwort lesen?
Header und Payload sind base64url-kodiert, nicht verschlüsselt, daher ist das Dekodieren nur eine umkehrbare Textumwandlung, keine Sicherheitsschranke — das ist so beabsichtigt, da JWTs für jede Partei lesbar sein sollen, die sie empfängt. Sensible Daten sollten aus genau diesem Grund nie in einer JWT-Payload stehen.
Was passiert, wenn der exp-Zeitstempel eines Tokens in der Vergangenheit liegt?
Ein JWT mit einem exp-Wert in der Vergangenheit gilt bei Systemen, die es prüfen, in der Regel als abgelaufen und sollte abgelehnt werden. Dieser Decoder zeigt jedoch nur das Datum an — er vergleicht es nicht mit der aktuellen Zeit und lehnt nichts ab, da diese Prüfung Aufgabe des Servers ist.
Warum zeigt mein dekodiertes Token einen Fehler an?
Ein Fehler bedeutet meist, dass der eingefügte Text kein vollständiges, wohlgeformtes JWT ist — zum Beispiel fehlt ein durch Punkt getrenntes Segment, Header oder Payload sind kein gültiges base64url, oder der dekodierte Text ist kein gültiges JSON. Prüfen Sie, ob Sie das gesamte Token ohne zusätzliche Leerzeichen oder Zeilenumbrüche kopiert haben.
Dieses Werkzeug dekodiert und zeigt nur Header und Payload an; es überprüft nie die Signatur, vergleicht den Ablauf nicht mit der aktuellen Zeit und validiert keinen Claim. Ein erfolgreich dekodiertes Token ist daher nicht dasselbe wie ein verifiziertes, vertrauenswürdiges Token.
Sources: RFC 7519 (JSON Web Token)
Datenschutz und Sicherheit
- Läuft im Browser — Ihre Eingaben werden ausschließlich auf Ihrem Gerät berechnet und nicht an einen utilduck-Server gesendet.
- Verschlüsselte Verbindung — Alle Seiten werden über HTTPS ausgeliefert, sodass niemand im Netzwerk mitlesen kann.
- Keine Weitergabe an Dritte — Ihre Eingaben werden nicht an Analyse- oder Werbedienste weitergegeben.
- Keine Speicherung — Ergebnisse werden auf keinem Server gespeichert, und ein Konto ist nicht nötig.
Zuletzt aktualisiert: 2026-08-17