Zum Inhalt springen

JWT-Decoder

Fügen Sie ein JSON Web Token oder einen kompletten Authorization-Header ein. Decodierung, Sicherheitsprüfung und HMAC-Verifizierung laufen nur in diesem Tab.

100 % lokale Ausführung im Browser • Kein Upload • Air-Gap-tauglich

100 % lokale Ausführung • Eingaben verlassen nie Ihren Browser WebCrypto HMAC

CtrlEnter zum Ausführen

Falsches Ergebnis, kaputtes Layout oder eine Idee? Schreiben Sie uns zu diesem Tool.

JWT-Decoder: JWT-Header, Payload und Signaturprüfung – Sicherheitsarchitektur-Banner

Dieser JWT-Decoder zerlegt ein JSON Web Token farbig in Header, Payload und Signatur, wandelt exp, iat und nbf in lesbare Zeitpunkte mit Live-Countdown um und prüft das Token auf Schwachstellen wie alg: none. Sie können ein Bearer-Token direkt aus dem Authorization-Header einfügen. Die Signaturprüfung für HS256, HS384 und HS512 läuft lokal über WebCrypto – anders als bei Online-Diensten verlässt kein Produktions-Token Ihren Rechner.

Aufbau eines JSON Web Tokens

Ein JWT besteht aus drei Base64URL-codierten Teilen, getrennt durch Punkte: header.payload.signature. Der Header nennt den Signaturalgorithmus (alg) und oft eine Schlüssel-ID (kid). Die Payload enthält Claims: registrierte wie iss (Aussteller), sub (Subjekt), aud (Zielgruppe), exp (Ablauf), nbf (gültig ab) und iat (ausgestellt am) sowie eigene Claims.

Die Signatur wird über die exakten Bytes base64url(header) + "." + base64url(payload) berechnet. Ändert sich ein einziges Zeichen, ist sie ungültig. Wichtig: Decodieren ist nicht Verifizieren. Jeder kann ein Token lesen, aber nur der Inhaber des Schlüssels kann eine gültige Signatur erzeugen.

So funktioniert es: JWT Inspector

JWT-Decoder: JWT-Header, Payload und Signaturprüfung – Architekturdiagramm. Diagramm der JWT-Prüfung: Das Token wird in Header, Payload und Signatur geteilt, Header und Payload werden per WebCrypto mit HMAC-SHA256 signiert und mit der Signatur verglichen, ergänzt um Prüfungen auf alg none und Ablauf.
Diagramm der JWT-Prüfung: Das Token wird in Header, Payload und Signatur geteilt, Header und Payload werden per WebCrypto mit HMAC-SHA256 signiert und mit der Signatur verglichen, ergänzt um Prüfungen auf alg none und Ablauf.

Die Sicherheitsprüfung im Überblick

Typische JWT-Schwachstellen entstehen, wenn Server dem Token selbst vertrauen, wie es geprüft werden soll. Der Decoder markiert diese Muster für Code-Reviews und Penetrationstests.

  • alg: none – ein unsigniertes Token. Server müssen es ablehnen, sonst ist die Authentifizierung umgangen.
  • Algorithmus-Verwechslung – ein RS256-Dienst, der auch HS256 akzeptiert, nutzt womöglich seinen öffentlichen Schlüssel als HMAC-Secret.
  • Fehlendes oder fernes exp – Tokens ohne Ablauf lassen sich nach einem Diebstahl nicht eindämmen.
  • Sensible Daten in der Payload – die Payload ist nur codiert, nicht verschlüsselt.
  • Verdächtiger kid – Pfade oder SQL im kid-Header deuten auf Angriffe auf die Schlüsselsuche hin.

HMAC-Signaturen lokal prüfen

Für HS256-, HS384- und HS512-Tokens geben Sie das gemeinsame Secret (als Text oder Base64) ein. Der Decoder importiert es mit crypto.subtle.importKey und prüft mit crypto.subtle.verify. Das Secret bleibt im Arbeitsspeicher der Seite und verschwindet beim Zurücksetzen oder Schließen des Tabs.

RS256-, ES256- und EdDSA-Tokens werden mit einem privaten Schlüssel signiert und mit dem öffentlichen Schlüssel geprüft, meist vom JWKS-Endpunkt des Ausstellers (/.well-known/jwks.json). Decodieren funktioniert auch für sie; vergleichen Sie den kid mit dem JWKS des Ausstellers.

Bearer-Tokens in der Praxis decodieren

Kopieren Sie den Wert nach Bearer aus dem Netzwerk-Tab Ihres Browsers oder aus einem Proxy. Der Decoder entfernt das Präfix automatisch. OAuth-2.0-Access-Tokens von Entra ID, Auth0, Okta, Cognito und Keycloak sind meist JWTs; undurchsichtige Tokens ohne drei Punkt-getrennte Teile lassen sich nur über den Introspection-Endpunkt des Ausstellers prüfen.

JWT-Claims-Spickzettel

Registrierte Claims und häufige Algorithmen.
FeldOrtBedeutung
algHeaderSignaturalgorithmus: HS256, RS256, ES256, EdDSA, none
kidHeaderSchlüssel-ID zur Auswahl des Prüfschlüssels
issPayloadAussteller des Tokens
subPayloadBenutzer oder Client, um den es geht
audPayloadZiel-API, die das Token akzeptieren soll
expPayloadAblaufzeit in Sekunden seit 1970
nbfPayloadNicht gültig vor diesem Zeitpunkt
iatPayloadAusstellungszeitpunkt

Registrierte Claims und häufige Algorithmen.

Beispiele für die Kommandozeile

JWT-Payload in der Shell decodieren

cut -d. -f2 <<< "$JWT" | tr "_-" "/+" | base64 -d 2>/dev/null | jq .

Mit PyJWT verifizieren

python -c "import jwt,sys; print(jwt.decode(sys.argv[1], sys.argv[2], algorithms=['HS256']))" "$JWT" "$SECRET"

Häufige Fragen

Die aktuelle Zeit liegt nach dem exp-Claim des Tokens, daher lehnt der Server es ab. Der Client muss ein neues Token holen, meist per Refresh-Token oder erneuter Anmeldung.