JWT Decoder
JSON Web Tokens dekodieren und prüfen
JWT-Token
Was ist ein JWT (JSON Web Token)?
Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Token-Format, das in RFC 7519 definiert ist. Es kodiert eine Menge von Claims als JSON-Objekt, signiert — und verschlüsselt optional — dieses, sodass der Empfänger überprüfen kann, dass die Daten nicht manipuliert wurden. JWTs sind der De-facto-Standard für zustandslose Authentifizierung in REST APIs, Single-Sign-On-Systemen und Microservice-Autorisierung.
JWT-Aufbau: Header · Payload · Signatur
Jeder JWT besteht aus drei base64url-kodierten Segmenten, die durch Punkte getrennt sind. Header und Payload sind einfaches JSON — für jeden lesbar — während die Signatur ein kryptografischer Wert ist, der nur mit dem richtigen Schlüssel verifiziert werden kann.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "user123",
"name": "Alice",
"role": "admin",
"iat": 1717200000,
"exp": 1717203600
}Warum einen JWT-Decoder verwenden?
Rohe JWTs sehen wie zufälliger Text aus. Dieses Tool rendert Header und Payload sofort als formatiertes JSON, sodass Sie Claims prüfen, Ablaufzeiten kontrollieren und Algorithmusentscheidungen auditieren können — ohne eine einzige Zeile Code zu schreiben.
Standard JWT Claims Referenz
RFC 7519 definiert sieben registrierte Claim-Namen. Diese sind nicht erforderlich, ihre Verwendung wird jedoch für die Interoperabilität dringend empfohlen. Sie können dem Payload beliebige benutzerdefinierte Claims hinzufügen.
| Claim | Beschreibung | Typ |
|---|---|---|
| iss | Aussteller — Identifiziert, wer das Token ausgestellt hat — z. B. die URL Ihres Auth-Servers oder den Anwendungsnamen. | string |
| sub | Subjekt — Identifiziert den Hauptakteur, auf den sich der JWT bezieht — typischerweise eine Benutzer-ID oder ein Dienstkonto. | string |
| aud | Zielgruppe — Identifiziert die vorgesehenen Empfänger. Die empfangende Partei muss prüfen, ob dies mit ihrer Kennung übereinstimmt. | string | string[] |
| exp | Ablaufzeit — Unix-Zeitstempel, nach dem das Token nicht mehr akzeptiert werden darf. Immer setzen, um den Schaden durch ein gestohlenes Token zu begrenzen. | number |
| nbf | Nicht vor — Unix-Zeitstempel, vor dem das Token nicht akzeptiert werden darf. Nützlich für zukünftig datierte Tokens. | number |
| iat | Ausgestellt um — Unix-Zeitstempel, zu dem das Token ausgestellt wurde. Wird zur Berechnung des Token-Alters verwendet. | number |
| jti | JWT ID — Ein eindeutiger Bezeichner für das Token. Ermöglicht den Widerruf durch serverseitiges Speichern und Prüfen verwendeter JTI-Werte. | string |
JWT-Signierungsalgorithmen
Der alg-Header-Claim gibt an, welcher Algorithmus das Token signiert hat. Die Wahl beeinflusst Sicherheit, Performance und ob Drittanbieter-Dienste Tokens ohne den privaten Schlüssel verifizieren können.
| Algorithmus | Familie | Schlüsseltyp | Hinweise |
|---|---|---|---|
| HS256 | HMAC | Symmetric | Am häufigsten verwendet. Gemeinsames Geheimnis — jeder mit dem Geheimnis kann signieren und verifizieren. |
| HS384 | HMAC | Symmetric | Stärkere HMAC-Variante; moderater Performance-Aufwand. |
| HS512 | HMAC | Symmetric | Stärkste HMAC-Variante. |
| RS256 | RSA | Asymmetric | Meistgenutzter asymmetrischer Algorithmus (Google, Auth0, Okta). Öffentlicher Schlüssel verifiziert ohne privaten Schlüssel. |
| RS384 | RSA | Asymmetric | RS-Variante mit höherer Sicherheit. |
| RS512 | RSA | Asymmetric | Stärkste RS-Variante. |
| ES256 | ECDSA | Asymmetric | Elliptische Kurve — kürzere Signaturen als RSA, beliebt auf Mobilgeräten und IoT. |
| PS256 | RSA-PSS | Asymmetric | RSA-PSS: moderner und sicherer als das auf PKCS1v1.5 basierende RS256. |
| none | — | — | Keine Signatur — kritisch gefährlich. Niemals Tokens mit alg: none in der Produktion akzeptieren. |
Sicherheitsüberlegungen
Ein JWT zu dekodieren ist immer sicher. Einem JWT ohne ordnungsgemäße Signaturverifizierung zu vertrauen, ist es nicht. Beachten Sie diese Regeln, wenn Sie Tokens in Ihrer Anwendung verwenden.
- –Einen JWT in den Entwicklertools oder in diesem Tool dekodieren und inspizieren
- –exp, iat und nbf verwenden, um die Token-Lebensdauer zu verstehen
- –Payload-Claims zum Debuggen protokollieren (sensible PII weglassen)
- –Den alg-Header lesen, um zu verstehen, wie das Token signiert wurde
- –Claims im Payload vertrauen, ohne die Signatur serverseitig zu verifizieren
- –Tokens mit alg: none akzeptieren — das bedeutet überhaupt keine Signatur
- –Zugriffs-Tokens in localStorage in sicherheitskritischen Anwendungen speichern (httpOnly-Cookies bevorzugen)
- –exp weit in die Zukunft setzen für Tokens mit sensiblen Berechtigungen
Häufige Anwendungsfälle
JWT in Code dekodieren
Header und Payload sind base64url-kodiert — die Kodierung einfach umkehren. Base64url ersetzt + durch - und / durch _, und lässt = als Auffüllung weg. Nur die Signatur benötigt den geheimen Schlüssel.
function decodeJWT(token) {
const [, payload] = token.split('.')
const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
return JSON.parse(json)
}const [, payload] = token.split('.')
const decoded = JSON.parse(
Buffer.from(payload, 'base64url').toString()
)import base64, json
def decode_jwt(token):
payload = token.split('.')[1]
padding = '=' * (-len(payload) % 4)
return json.loads(base64.urlsafe_b64decode(payload + padding))TOKEN="eyJhbGc..." echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .