Ansicht in Deutsch Auf Englisch wechseln

JWT-Decoder

Einen JSON Web Token dekodieren und inspizieren. Signaturprüfung braucht den Signierschlüssel und muss serverseitig passieren — dieses Tool zeigt nur die Inhalte an.

  1. Kopiere den JWT aus deiner App, der API-Antwort oder dem Authorization-Header.
  2. Füge ihn ins Feld ein. Dekodierung läuft beim Tippen automatisch.
  3. Lies den dekodierten Header und das Payload; die Signatur wird zum Nachschauen unverändert angezeigt.
  4. Prüfe die Zusammenfassung der Zeit-Claims (iat, exp, nbf), um abgelaufene Tokens zu erkennen.
Was macht es?

Ein JSON Web Token sind drei base64url-kodierte Segmente, die durch Punkte verbunden sind: header.payload.signature. Header und Payload sind JSON; die Signatur ist eine HMAC- oder RSA/ECDSA-Ausgabe über die ersten beiden Segmente. Dieses Tool teilt an den Punkten, dekodiert jedes Teil per base64url, parst das JSON und zeigt Standard-Zeit-Claims wie exp als lesbare Daten. Die Signatur wird nicht verifiziert — warum, steht in den FAQ unten.

Beispiel

Der Beispieltoken aus der JWT-Spezifikation (HS256, signiert mit dem Secret your-256-bit-secret):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Dekodierter Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

Dekodiertes Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Warum wird meine JWT-Signatur als ungültig markiert?

Dieser Decoder prüft keine Signaturen (siehe FAQ), aber wenn ein serverseitiger Verifier deinen Token ablehnt, sind das die üblichen Verdächtigen.

  • Falsches Secret oder falscher Schlüssel. Schon ein einzelnes Zeichen Unterschied im HMAC-Secret ergibt eine komplett andere Signatur. Prüfe, ob die Env-Variable JWT_SECRET im validierenden Service mit dem Issuer übereinstimmt.
  • Algorithmus-Mismatch. Ein mit HS256 signierter Token lässt sich nicht mit RS256 verifizieren. Prüfe den alg-Claim im Header und stelle sicher, dass der Verifier auf denselben Algorithmus eingestellt ist.
  • Abgelaufener Token. Selbst ein korrekt signierter JWT schlägt die Validierung fehl, sobald exp in der Vergangenheit liegt. Die Zeit-Claims-Zusammenfassung zeigt das nach dem Dekodieren explizit.
  • Uhrzeitabweichung. nbf (not-before) leicht in der Zukunft plus Server-Clock-Drift erzeugt "token not yet valid"-Fehler. Räume im Verifier eine kleine Toleranz ein (z. B. 60 Sekunden).
  • Whitespace im eingefügten Token. Copy-Paste schleppt manchmal ein führendes Leerzeichen oder einen abschließenden Zeilenumbruch mit. Ein JWT muss genau header.payload.signature ohne umgebenden Whitespace sein.
  • alg: none. Sagt der Header "alg": "none", ist der Token unsigniert. Lehne solche im Verifier ab — behandle sie nie als gültig.
Häufig gestellte Fragen

Kann dieses Tool die JWT-Signatur verifizieren?

Nein, und das ist so gewollt. Eine Signatur zu verifizieren braucht den Signierschlüssel — ein HMAC-Shared-Secret oder einen asymmetrischen Public Key. Dieser Schlüssel gehört auf den Server, der den Token ausstellt oder verarbeitet, nicht in eine Webseite. Dieses Tool dekodiert und zeigt nur; die Verifikation passiert serverseitig in deinem Backend.

Was steckt in jedem der drei JWT-Segmente?

Ein JWT ist header.payload.signature. Der Header ist JSON und beschreibt Algorithmus (alg) und Token-Typ. Das Payload ist JSON mit Claims wie sub, iat, exp. Die Signatur ist die base64url-kodierte Ausgabe, die entsteht, wenn die ersten beiden Segmente mit dem Secret oder Private Key signiert werden. Die ersten beiden sind nur kodiert, nicht verschlüsselt.

Mein JWT ist abgelaufen — wie erkenne ich das?

Schau auf den exp-Claim im Payload. Das ist ein Unix-Timestamp in Sekunden. Ist Date.now() / 1000 größer als exp, ist der Token abgelaufen. Dieses Tool rendert exp, iat und nbf als lesbare Daten unter dem Payload, damit du es mit einem Blick siehst, ohne selbst zu rechnen.

Was bedeutet alg: none und warum ist das gefährlich?

alg: none ist ein JWT-Feature, bei dem die Signatur leer ist und nicht geprüft wird. Viele Bibliotheken haben solche Tokens historisch akzeptiert und Angreifern erlaubt, JWTs zu fälschen, indem sie ein Payload bauen und alg auf none setzen. Siehst du diesen Header-Wert, ist der Token unsigniert — vertraue keinem Server, der ihn akzeptiert.

Speichert ihr die JWTs, die ich hier einfüge?

Nein. Wir speichern keinen Token, den du in den Decoder einfügst. Was du einwirfst, wird verworfen, wenn du den Tab schließt oder aktualisierst — keine Logs, keine Aufzeichnung bei uns über die von dir inspizierten Tokens. Trotzdem: Ein JWT gewährt Zugriff bis zu seinem exp: behandle ihn wie ein Passwort und rotiere jeden Produktionstoken, den du debuggst.

Der Signaturbereich zeigt einen unlesbaren Blob — normal?

Ja. Die Signatur ist Binärausgabe von HMAC oder RSA/ECDSA, base64url-kodiert. Sie ist nicht zum Lesen gedacht — sie dient nur als kryptografische Prüfung. Die dekodierten Header- und Payload-Teile sind die JSON-Bestandteile, mit denen du arbeitest. Eine leere Signatur bedeutet, der Token ist unsigniert (alg: none).