MyDevTools
DE

JWT-Decoder

JWT-Header und -Payload im Browser dekodieren, exp/nbf/iat prüfen und HS256/384/512- oder RS256/384/512-Signaturen verifizieren. Tokens bleiben auf dem Gerät.

Eingaben und Dateien bleiben im Browser

Möchten Sie ein JWT generieren? Probieren Sie den JWT-Encoder

Fügen Sie ein JWT (header.payload.signature) ein oder laden Sie ein Demo-Token.

Signatur verifizieren

Dekodiert

Header, Payload und Zeit-Claims erscheinen hier, sobald Sie ein Token einfügen.

Auf dieser Seite

Fügen Sie ein JSON Web Token ein und sehen Sie Header und Payload als formatiertes JSON, den Signaturalgorithmus sowie Ausstellung, Gültigkeitsbeginn und Ablauf. Optional prüfen Sie die Signatur mit einem gemeinsamen Secret oder einem öffentlichen RSA-Schlüssel.

Detaillierte Funktionalität

Dekodiert wird beim Tippen: Header und Payload werden aus base64url dekodiert und in der ursprünglichen Claim-Reihenfolge des Tokens formatiert. Ein vorangestelltes Bearer und aus einem HTTP-Header kopierte Zeilenumbrüche werden automatisch entfernt. Die registrierten Zeit-Claims exp, nbf und iat erscheinen als Datum in Ihrer lokalen Zeitzone; abgelaufene oder noch nicht gültige Tokens werden markiert.

Die Signaturprüfung läuft in einem Rust-Kryptografiemodul, kompiliert zu WebAssembly, mit dem im Token-Header genannten Algorithmus: HS256, HS384 und HS512 mit einem gemeinsamen Secret (als UTF-8-Text verwendet), RS256, RS384 und RS512 mit einem öffentlichen RSA-Schlüssel im PEM-Format (BEGIN PUBLIC KEY oder BEGIN RSA PUBLIC KEY). Stattdessen können Sie ein JWK oder JWKS einfügen (zum Beispiel aus /.well-known/jwks.json eines Identitätsanbieters): Der Schlüssel wird über die kid des Tokens gewählt (ohne kid werden alle zum Algorithmus passenden Schlüssel probiert) und mit der Web Crypto API des Browsers geprüft – das deckt auch PS256/384/512, ES256/384/512 und EdDSA (Ed25519) ab. Ein Token mit alg: none gilt immer als unsigniert, nie als gültig.

Tokens und Schlüssel bleiben auf der Seite: Nichts wird an einen Server gesendet oder gespeichert. Bedenken Sie: Dekodieren beweist nichts über die Echtheit – das tut nur eine verifizierte Signatur.

Praktische Beispiele

jwt.io-Beispiel: Das Token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIi… ergibt den Header {"alg":"HS256","typ":"JWT"} und eine Payload mit sub, name und iat; das Secret your-256-bit-secret liefert „Signatur verifiziert“, jedes andere „Ungültige Signatur“.

Abgelaufenes Token: Eine Payload mit "exp": 1767225600 wird als am 1. Januar 2026 abgelaufen markiert (angezeigt in Ihrer lokalen Zeitzone).

Aus einem Authorization-Header: Fügen Sie Bearer eyJ… unverändert ein – Präfix und Zeilenumbrüche werden vor dem Dekodieren entfernt.

Unsigniertes Token: eyJhbGciOiJub25lIn0.eyJzdWIiOiIxIn0. ergibt {"alg":"none"} und {"sub":"1"} und wird als unsigniert und nicht vertrauenswürdig gemeldet.

So verwenden Sie dieses Tool

  1. Token einfügen

    Fügen Sie das JWT in Kodiertes JWT ein; das Dekodieren beginnt sofort.

  2. Header und Payload lesen

    Prüfen Sie den formatierten Header und die Payload, das Algorithmus-Badge und die Daten für Ausstellung, Gültigkeit und Ablauf unter der Payload.

  3. Signatur verifizieren

    Geben Sie unter Signatur verifizieren das HMAC-Secret oder den öffentlichen PEM-Schlüssel in Secret / öffentlicher RSA-Schlüssel ein. Der Status zeigt, ob die Signatur gültig ist.

Tipps und Best Practices

  • Jeder kann ein JWT dekodieren: Legen Sie nie Passwörter oder andere Geheimnisse in die Payload.
  • Das HMAC-Secret wird genau so verwendet, wie es eingegeben wurde. Speichert Ihr Backend es base64-kodiert, dekodieren Sie es zuerst – der base64-String ergibt „Ungültige Signatur“.
  • Für RS*-Tokens den öffentlichen Schlüssel einfügen, nicht den privaten; ein X.509-Zertifikat wird nicht akzeptiert, extrahieren Sie zuerst dessen öffentlichen Schlüssel.
  • Der Ablauf wird mit der Uhr Ihres Geräts verglichen; eine falsche Systemzeit führt zu einer falschen Ablauf-Markierung.
  • Brauchen Sie ein Token zum Testen? Erstellen Sie eines mit dem JWT-Kodierer.