HandyTools Hub

🔐 JWT-Decoder

JSON Web Tokens dekodieren und überprüfen.

🔒 Ihre Daten verlassen niemals Ihren Browser

Ein JSON Web Token besteht aus drei Base64url-kodierten Teilen, getrennt durch Punkte: einem Header, einer Payload und einer Signatur. Dieser Decoder zerlegt das Token, dekodiert Header und Payload und formatiert sie als JSON. Er zeigt außerdem den Signaturalgorithmus, den Token-Typ und ob die Zeitangaben der Payload das Token in die Vergangenheit oder Zukunft versetzen. Er überprüft die Signatur nicht und kann nicht sagen, ob ein Token vertrauenswürdig ist.

Verwendung

  1. Fügen Sie ein Token in das Eingabefeld ein. Die Dekodierung beginnt, sobald das Feld Inhalt enthält.
  2. Lesen Sie die Token-Infozeile: Algorithmus, Typ, Ablaufstatus und das Ablaufdatum, falls vorhanden.
  3. Prüfen Sie die Bereiche Header und Payload, die das dekodierte JSON anzeigen.
  4. Lesen Sie den Bereich Signatur, der das rohe Base64url-Segment zeigt. Kopieren Sie bei Bedarf Inhalte aus den Bereichen, indem Sie sie markieren.

Ist die Eingabe leer, werden die Bereiche ausgeblendet. Ist das Token fehlerhaft, erklärt eine Fehlermeldung, ob der Header, die Payload oder das Gesamtformat betroffen ist.

Was die drei Teile enthalten

  • Header — ein kleines JSON-Objekt, das beschreibt, wie das Token signiert wurde. Das Feld alg nennt den Algorithmus (zum Beispiel HS256 oder RS256), und typ ist meistens JWT. Ein kid kann angeben, welcher Schlüssel verwendet wurde.
  • Payload — die Claims. Registrierte Claims sind iss (Aussteller), sub (Subjekt), aud (Empfänger), exp (Ablauf), nbf (nicht vor), iat (ausgestellt am) und jti (Token-ID). Anwendungen fügen eigene Claims wie Rollen oder eine Benutzer-ID hinzu.
  • Signatur — die kryptografische Ausgabe. Sie ist binär und Base64url-kodiert, daher zeigt der Decoder sie als String statt als JSON.

Base64url ist eine URL-sichere Variante von Base64: Sie verwendet - und _ statt + und /, und das Auffüllzeichen = wird häufig weggelassen. Der Decoder stellt das Auffüllen vor dem Dekodieren wieder her.

Dekodieren ist keine Verifikation

Das ist die wichtigste Einschränkung. Die Base64url-Dekodierung ist umkehrbar und benötigt überhaupt keinen Schlüssel, sodass Header und Payload für jeden lesbar sind, der das Token besitzt — sie sind weder geheim noch verschlüsselt. Ein Token lässt sich mit jeder beliebigen Payload herstellen, und es wird hier einwandfrei dekodiert. Der Decoder prüft nie die Signatur, validiert nie iss oder aud und lehnt nie einen schwachen Algorithmus ab. Ein Token, dessen Header den Algorithmus alg auf none setzt, wird anstandslos dekodiert — genau deshalb darf dekodierter Inhalt niemals eine Autorisierungsentscheidung steuern. Vertrauen entsteht nur durch die Überprüfung der Signatur mit dem korrekten geheimen oder öffentlichen Schlüssel und die Validierung der erwarteten Claims auf dem Server.

exp, nbf und iat lesen

JWT-Zeitangaben sind NumericDate-Werte: Sekunden seit der Unix-Epoche in UTC, nicht Millisekunden. exp ist der Moment, in dem das Token abläuft, nbf der früheste Moment, in dem es verwendet werden darf, und iat hält fest, wann es ausgestellt wurde. Der Decoder vergleicht exp und nbf mit Ihrer lokalen Uhr und kennzeichnet das Token als gültig, abgelaufen oder noch nicht gültig; das Ablaufdatum gibt er als lesbares Datum aus. Da der Vergleich die Uhr Ihres Rechners verwendet und rein informativ ist, kann ein Gerät mit falscher Zeit eine irreführende Kennzeichnung anzeigen. Ein Token ohne exp-Claim läuft nach dieser Prüfung nie ab und wird als gültig gekennzeichnet — auch das ist ein Fehlen von Belegen, kein Beweis für Sicherheit.

Praxisbeispiel

Nehmen Sie das kanonische Beispieltoken:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Der Header dekodiert zu {"alg":"HS256","typ":"JWT"}, sodass der Algorithmus als HS256 und der Typ als JWT erscheint. Die Payload dekodiert zu {"sub":"1234567890","name":"John Doe","iat":1516239022}, einem Ausstellungszeitpunkt vom 22. Januar 2018. Es gibt kein exp und kein nbf, daher lautet der Status gültig und der Ablauf zeigt keine Ablauffrist. Der Signaturbereich zeigt das letzte Segment als Rohtext. Nichts an dieser Ausgabe beweist, dass das Token von einer bestimmten Stelle signiert wurde.

Hätte die Payload zusätzlich ein exp, würde die Kennzeichnung diesem Zeitstempel folgen statt dem Inhalt des Tokens: Dieselbe Zeichenkette wäre bis zum Ablaufmoment gültig und kippte danach auf abgelaufen, ohne dass sich das Token selbst ändert.

Häufige Dekodierfehler

  • „Invalid JWT format: expected 3 parts.“ Der häufigste Fehler. Er bedeutet, dass die durch Punkte getrennte Struktur beschädigt ist — ein abgeschnittener Einfügevorgang, ein Token mit angehängtem HTTP-Bearer-Präfix, umgebende Anführungszeichen oder ein Token mit nur zwei Segmenten.
  • „Invalid header: not valid base64 encoding.“ Das erste Segment enthält Zeichen, die weder Base64url noch wiederhergestelltes Auffüllen sind; das deutet meist auf eine teilweise Kopie oder einen Token-Typ hin, der kein JWT ist.
  • „Invalid header: not valid JSON.“ Das Segment lässt sich aus Base64url dekodieren, aber der resultierende Text ist kein JSON. Das kann passieren, wenn das falsche Segment an erster Stelle steht oder das Token verändert wurde.
  • Ein Wert mit fünf Segmenten. Das ist ein JWE (verschlüsseltes Token), kein signiertes JWT. Sein Inhalt ist Chiffretext und ohne Entschlüsselungsschlüssel nicht lesbar, daher lehnt dieser Decoder es ab.
  • Prozentkodierte Eingabe. Ist das Token über eine URL angekommen und enthält noch %2E oder ähnliche Escapes, sind die Punkte verborgen und die Aufteilung findet nie statt. Dekodieren Sie zuerst die URL.

Der Decoder entfernt vor dem Parsen Leerraum, daher sind Zeilenumbrüche aus einer umbrochenen Kopie unschädlich; fast jeder andere Fehler entsteht durch zusätzliche oder fehlende Zeichen.

Verwandte Tools

Häufig gestellte Fragen

Bedeutet eine erfolgreiche Dekodierung, dass das Token gültig oder vertrauenswürdig ist?

Nein. Dekodieren heißt nur, Header und Payload aus Base64url zu dekodieren und als JSON zu parsen. Es prüft weder die Signatur noch den Aussteller, den Empfänger oder den Algorithmus. Jeder kann einen wohlgeformten Header und eine Payload ohne jeden Schlüssel bauen, ein grüner Status hier sagt also nichts darüber aus, ob ein Server das Token akzeptieren sollte. Verifizieren Sie Signatur und Claims immer serverseitig mit dem richtigen geheimen oder öffentlichen Schlüssel.

Wie bestimmt der Decoder den Ablaufstatus?

Er vergleicht die numerischen Claims exp und nbf mit der aktuellen Uhrzeit Ihres Rechners und rechnet sie von Unix-Sekunden in ein lokales Datum um. Liegt exp in der Vergangenheit, gilt das Token als abgelaufen; liegt nbf in der Zukunft, als noch nicht gültig; andernfalls als gültig. Diese Kennzeichnung dient nur der Anzeige und nutzt Ihre lokale Uhr, eine Uhrverschiebung oder ein fehlendes exp-Claim kann sie also ändern, ohne dass das Token sicherer oder unsicherer wird.

Warum wird die Signatur als Rohtext statt als dekodiertes JSON angezeigt?

Die Signatur sind Binärdaten, die mit Base64url kodiert sind, kein JSON-Dokument. Ein Dekodieren würde unlesbare Bytes statt strukturierter Claims ergeben, daher zeigt das Tool die kodierte Zeichenkette genau so, wie sie im Token steht. Nur Header und Payload sind JSON und werden deshalb formatiert ausgegeben.

Warum schlägt mein Token mit einem Formatfehler fehl?

Der Decoder erwartet genau drei durch Punkte getrennte Segmente. Ein Token mit zwei oder vier Segmenten, einem fehlenden Segment oder einem überzähligen Punkt wird abgelehnt. Kopieren Sie das Token genau so, wie es ausgestellt wurde, ohne Zeilenumbrüche einzufügen oder die Signatur zu kürzen, und stellen Sie sicher, dass kein umgebender Text mitkopiert wurde.

Warum könnte ein Token, das in meiner App funktioniert, hier fehlschlagen?

Der Decoder entfernt vor dem Parsen allen Leerraum, Zeilenumbrüche sind also unschädlich. Er versteht aber keine HTTP-Syntax und keine Kodierungsverpackung. Haben Sie den Wert samt Bearer-Präfix, umgebenden Anführungszeichen oder als URL-kodierte Kopie eingefügt, ist die Dreiteilung beschädigt und das Parsen schlägt fehl. Fügen Sie nur die rohe Token-Zeichenkette ein.

Ist es sicher, ein Produktions-Access-Token in diese Seite einzufügen?

Die Dekodierung erfolgt lokal im Browser, die Zeichenkette wird vom Tool also nirgendwohin gesendet. Dennoch ist ein JWT ein Inhaber-Ausweis: Wer es besitzt, kann bis zum Ablauf möglicherweise als der Benutzer handeln. Fügen Sie keine aktiven Produktions-Token in irgendeine Webseite ein, auch nicht in diese, es sei denn, Sie sind sicher, und rotieren Sie das Token, falls es je offengelegt wurde.

Geprüft vom HandyTools-Hub-Team · Zuletzt aktualisiert