JWT Decoder

Ein JSON Web Token wirkt auf den ersten Blick wie eine unleserliche Zeichenkette, ist in Wirklichkeit aber nur drei Base64URL-codierte Teile, die durch Punkte verbunden sind: ein Header, eine Payload und eine Signatur. Das Decodieren von Header und Payload hat nichts mit Verschlüsselung zu tun — jeder, der das Token besitzt, kann die enthaltenen Claims lesen. Genau deshalb gehören sensible Daten niemals in eine JWT-Payload. Das eigentliche Problem: Die Tokens, die man untersuchen muss, sind selten harmlose Testdaten. Oft handelt es sich um ein aktives Session-Token aus einer Produktivanwendung, ein API-Zugriffstoken oder ein Login-Cookie, das man beim Debuggen direkt aus den Dev-Tools des Browsers kopiert hat — also um ein echtes Credential, das in den falschen Händen echten Zugriff ermöglicht. Wer so ein Token auf einer beliebigen Website einfügt, gibt seine Session an einen Server weiter, über den er nichts weiß.

Dieses Tool tut das nicht. Header und Payload werden mit reinem JavaScript im Browser decodiert, sobald du ein Token einfügst — an den Punkten aufgeteilt, Base64URL-decodiert, als JSON geparst — und nichts davon wird irgendwohin übertragen. Die Signaturverifizierung funktioniert nach demselben Prinzip, mithilfe der Web Crypto API (`SubtleCrypto`), die in jedem modernen Browser eingebaut ist: HMAC-Algorithmen (HS256, HS384, HS512) werden gegen ein von dir eingegebenes Secret geprüft, RSA-Algorithmen (RS256, RS384, RS512) gegen einen Public Key, den du im PEM-Format einfügst. Sowohl das kryptografische Secret als auch die Verifizierung selbst bleiben lokal im Tab — nach einem Neuladen der Seite sind Token, Secret und Key spurlos verschwunden.

Füge ein Token ein, um Header und Payload übersichtlich formatiert zu sehen, zusammen mit einer Auswertung der Standard-Claims `exp`, `iat` und `nbf`, umgerechnet in ein lesbares Datum — inklusive eines klaren "Abgelaufen"-Badges, falls das `exp` des Tokens bereits verstrichen ist. Praktisch, um bei einem Bugreport wie "ich wurde ausgeloggt" schnell zu prüfen, ob es sich schlicht um ein abgelaufenes Token handelt. Bei HS256/384/512 oder RS256/384/512 kannst du das passende Secret oder den Public Key eingeben, um zu prüfen, ob die Signatur echt oder manipuliert ist. Algorithmen außerhalb dieser Liste (etwa ES256 oder das unsignierte `none`) werden trotzdem korrekt decodiert, nur die Verifizierung wird dafür nicht angeboten, statt ein falsches Ergebnis vorzutäuschen. Für die lokale Entwicklung lassen sich Header und Payload direkt bearbeiten — etwa um eine User-ID oder eine Rolle zu ändern — und das Token anschließend mit demselben HS256-Secret neu signieren, das auch dein Testserver verwendet. Das ist eine gängige Methode, um Autorisierungslogik zu testen, ohne einen kompletten Login-Flow aufzusetzen.

Da die Payload eines JWT nach dem Decodieren einfaches, lesbares JSON ist, lässt sie sich hervorragend mit dem JSON Formatter & Validator kombinieren, wenn du einen tief verschachtelten Claim genauer untersuchen willst. Ein Sicherheitshinweis, der es wert ist, wiederholt zu werden: Da für das Decodieren gar kein Secret nötig ist, solltest du jedes Token, sobald du es geprüft hast, als sensibel behandeln — und Zugangsdaten, die eigentlich nur kurzlebig sein sollten, rotieren, falls du nicht sicher bist, wo sie sonst noch eingefügt wurden, bevor sie hier gelandet sind.