JWT-Decoder

Ein JWT besteht aus drei Base64URL-kodierten Segmenten, getrennt durch Punkte: Header.Payload.Signature. Der Header beschreibt Token-Typ und Signing-Algorithmus (z. B. HS256, RS256). Der Payload trägt Claims — User-ID, Roles, Expiry (exp), Issued-at (iat) und Custom Fields Ihrer API. Die Signature ist ein kryptografisches Siegel über die ersten beiden Teile; dieser Decoder zeigt den rohen Signature-String, verifiziert ihn aber nicht — dafür braucht es Secret oder Public Key.

Dekodieren Base64URL-dekodiert nur Header und Payload, damit Sie Claims lesen — das kann jeder ohne Key, weil JWTs signed, nicht encrypted sind. Verifizieren prüft, dass die Signature mit Secret oder Public Key des Issuers matcht — Beweis, dass das Token nicht manipuliert wurde und von einer trusted Party kommt. Dieses Tool ist ein Decoder zum Debuggen; es behauptet nie Authentizität, außer Sie verifizieren separat im eigenen Backend.

Diese Claims sind Unix-Zeit in Sekunden seit 1970-01-01 UTC. Dieses Tool erkennt gängige Timestamp-Keys (exp, iat, nbf, auth_time) und zeigt das lokale Datum/Uhrzeit daneben. Bei exp badgt es das Token zusätzlich als Expired oder Active anhand der Browser-Uhr — nützlich für Clock-Skew oder stale Staging-Tokens.

Production- und Staging-JWTs enthalten oft User-IDs, E-Mails, Roles oder andere PII im Payload — und manchmal fügen Leute Tokens ein, die auch in Authorization-Headern neben Secrets stehen. Ein Server-Debugger empfängt den gesamten String. Dieses Tool lädt nie etwas hoch: Base64URL-Decoding, JSON-Parsing und Timestamp-Formatierung laufen im Browser — sensible Tokens bleiben auf Ihrer Maschine.