JWT-Decoder

Was ist ein JWT?#

Ein JWT (JSON Web Token, definiert in RFC 7519) ist ein kompaktes, URL-sicheres Token, das gebaut wurde, um Claims zwischen zwei Parteien zu transportieren. Es ist das Credential, das Ihr Browser nach dem Login an eine API sendet, die Identitäts-Behauptung, die ein OAuth-Provider einer vertrauenden Applikation aushändigt, und der Umschlag, in dem die meisten modernen Session- und Zugriffssteuerungs-Flows reisen. Der Reiz ist, dass die Claims — wer der Nutzer ist, was er darf, wann das Token abläuft — innerhalb des Tokens selbst als JSON reisen, sodass der empfangende Dienst sie ohne Datenbank-Lookup lesen kann.

Ein JWT hat exakt drei base64url-kodierte, durch Punkte getrennte Teile: header.payload.signature. Der Header benennt Algorithmus und Token-Typ. Der Payload ist ein JSON-Objekt aus Claims — registrierte wie sub (Subject), iat (ausgestellt am), exp (Ablauf), nbf (nicht vor), plus beliebige benutzerdefinierte Claims, die Ihre Applikation hinzufügt. Die Signatur ist das, was der Aussteller über die anderen beiden Teile mit einem Secret oder privaten Schlüssel berechnet hat; sie zu verifizieren beweist, dass das Token nicht manipuliert wurde.

Diese Seite dekodiert und inspiziert ein JWT. Sie trennt die drei Teile, base64url-dekodiert Header und Payload in lesbaren JSON, hebt die Standard-Zeit-Claims als menschenlesbare Zeitstempel hervor und zeigt ein Live-Status-Badge (Gültig, Abgelaufen, Noch nicht gültig). Sie verifiziert bewusst nicht die Signatur — das erfordert das Secret oder den öffentlichen Schlüssel des Ausstellers und ist out of scope für ein 100 %-clientseitiges Werkzeug. Das Signatur-Segment wird roh angezeigt, exakt wie empfangen.

So wird es verwendet#

1. Fügen Sie Ihr Token in das Feld Eingabe links ein. Es muss drei punktgetrennte Segmente sein; Whitespace darum wird automatisch entfernt.
2. Klicken Sie auf Beispiel, um ein eingebautes Beispiel-Token (mit iat/exp/nbf) zu laden, wenn Sie nur sehen möchten, wie das Layout funktioniert.
3. Klicken Sie auf Leeren, um Eingabe und Ergebnis-Spalten zu leeren.
4. Lesen Sie das rechte Panel:
   • Das Status-Badge oben — grün Gültig, Abgelaufen oder Noch nicht gültig — basierend auf den nbf- und exp-Claims im Vergleich zur aktuellen Zeit.
   • Die Header-Karte (mit dem Algorithmus in ihrer Titelleiste, z. B. HS256).
   • Die Payload-Karte, hübsch gedruckt als JSON.
   • Die Zeit-Claims-Liste — Ausgestellt am, Nicht vor, Läuft ab — jedes sowohl als Unix-Zeitstempel als auch als lesbares Datum dargestellt.
   • Das Signatur-Segment, roh gezeigt, weil es noch base64url-kodierte Bytes sind.
5. Ist das Token missgebildet, sagt Ihnen die rote Statuszeile, ob es an der Drei-Segment-Form, der base64url-Dekodierung oder dem JSON-Parse scheiterte.

Die wichtigsten Funktionen#

• Live-Zeit-Claim-Status. Liest iat, nbf und exp und sagt Ihnen, ob das Token aktuell gültig, bereits abgelaufen oder noch nicht in Kraft ist — die drei Fragen, die man bei einem Login-Bug tatsächlich stellt.
• Menschenlesbare Daten. Unix-Epoch-Zahlen wie 1700000000 werden neben dem UTC-Datum gezeigt, das sie repräsentieren, sodass Sie aufhören, Epoch-Arithmetik im Kopf zu machen.
• Algorithmus sichtbar. Der alg-Wert des Headers wird in die Titelleiste der Header-Karte gezogen, sodass Sie sofort sehen, ob Sie ein HS256, RS256 oder etwas Unerwartetes in der Hand halten.
• UTF-8-sichere Dekodierung. Base64url-Segmente werden als Bytes über TextDecoder dekodiert, sodass nicht-ASCII-Claims (Namen, Rollen in anderen Schriften) korrekt rendern statt als Mojibake.
• Nur dekodieren — niemals verifizieren. Das Werkzeug fragt nie nach einem Secret, was es sicher macht, Tokens einzufügen, denen Sie nicht voll vertrauen: nichts wird irgendwohin gesendet, und die Signatur wird gezeigt, aber nicht geprüft.

Anwendungsbeispiel#

Klicken Sie auf Beispiel und die Eingabe füllt sich mit einem Token, dessen Header dekodiert zu:

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

und dessen Payload dekodiert zu:

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

Die Zeit-Claims-Liste zeigt dann:

Ausgestellt am  1700000000  (2023-11-14 22:13:20 UTC)
Nicht vor       1699999000  (2023-11-14 21:56:40 UTC)
Läuft ab        4102444800  (2100-01-01 00:00:00 UTC)

Das Status-Badge liest Gültig, weil die aktuelle Zeit nach nbf und vor exp liegt. Das Signatur-Segment wird als die wörtliche Zeichenkette c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ gezeigt — was als der Text „sample-signature-not-verified“ dekodiert, ein bewusster Marker, dass die Signatur dieses Tokens illustrativ ist, kein echter HMAC-SHA256-Output.

Dieser letzte Punkt ist das Wichtigste, das man über dieses Werkzeug verstehen muss: ein Token, das sauber dekodiert, ist nicht zwingend ein Token, das vertrauenswürdig ist. Jeder kann Header und Payload fälschen; nur die Signatur, geprüft gegen das Secret oder den öffentlichen Schlüssel des Ausstellers, beweist Authentizität. Nutzen Sie diese Seite, um Claims zu lesen und Zeitfenster zu debuggen; verifizieren Sie Signaturen in Ihrem echten Backend.

FAQ#

Kann mir dieses Werkzeug sagen, ob ein JWT authentisch ist?#

Nein, und das ist by Design. Dekodieren liest nur das JSON innerhalb des Tokens — es beweist nicht, dass das Token von dem ausgestellt wurde, der behauptet, es ausgestellt zu haben. Um Authentizität zu verifizieren, brauchen Sie den zum alg passenden Schlüssel (ein Shared Secret für HS256, den öffentlichen Schlüssel des Ausstellers für RS256/ES256) und eine Verifizierungsroutine auf einem vertrauenswürdigen Backend. Behandeln Sie ein sauber dekodiertes Token nie als verifiziert.

Der Status sagt „Abgelaufen“. Kann ich das Token hier erneuern?#

Nein. Erneuern heißt, den Refresh-Endpunkt Ihres Authentifizierungs-Servers aufzurufen, um ein neues Access-Token zu bekommen — eine Netzwerkoperation, die diese statische, clientseitige Seite nicht durchführen kann und sollte. Was Sie hier tun können, ist genau zu bestätigen, wann das alte Token abgelaufen ist, was normalerweise der Hinweis ist, den Sie brauchten.

Was ist der Unterschied zwischen iat, nbf und exp?#

iat (ausgestellt am) ist, wann das Token erzeugt wurde — informativ. nbf (nicht vor) ist die früheste Zeit, zu der das Token akzeptiert werden sollte; vor nbf sollte ein validierender Server es ablehnen, selbst wenn die Signatur gültig ist. exp (Ablauf) ist der harte Cutoff, nach dem das Token abgelehnt werden muss. Ein wohlgebildetes Token hat nbf ≤ iat ≈ jetzt und exp irgendwo in naher Zukunft (Minuten für Access-Tokens, länger für Refresh-Tokens).

Mein Payload enthält Nicht-ASCII-Zeichen und sie woanders verstümmelt. Warum stimmen sie hier?#

Weil manche Decoder fälschlich jedes base64url-Zeichen als ein Byte behandeln, statt zuerst zu rohen Bytes zu dekodieren. Diese Seite dekodiert zu einem Uint8Array und jagt es dann durch TextDecoder, der die Bytes als korrektes UTF-8 interpretiert. Das ist der korrekte Weg, und deshalb rendern Namen, Rollen und Scopes in jeder Schrift wie geschrieben.