Encoders & Utilities

JWT-Decoder

JWT-Header und -Payload sicher im Browser dekodieren.

JWT token Paste a JWT — we will split it into header, payload, and signature.

Über dieses Tool

JWT Decoder zerlegt einen JSON Web Token in seine drei Bestandteile: Header (Algorithmus, Token-Typ), Payload (Claims wie sub, iat, exp, iss) und Signatur. Header und Payload sind Base64url-kodiertes JSON und vollständig lesbar — die Signatur ist eine kryptografische Bestätigung, dass die anderen Teile nicht manipuliert wurden, aber sie ist nicht der Schlüssel selbst.

Das Tool dekodiert vollständig im Browser. Sie sehen die drei Teile farblich getrennt, lesbar formatiert; gängige Standard-Claims werden mit Mensch-lesbaren Beschreibungen annotiert (exp wird als Datum angezeigt, iat ebenso). Eine Verfallsbewertung warnt, wenn das Token bereits abgelaufen ist oder gerade jetzt abläuft. Algorithmus-Hinweise machen aufmerksam auf bekannte Schwächen (alg: none = niemals akzeptieren!).

Wann Sie dieses Tool nutzen sollten

API-Auth-Debugging. Sehen, welche Claims ein Token enthält und ob es abgelaufen ist.
OAuth-Flow-Inspektion. Was hat der Identity Provider in das Access Token gepackt?
Audit von Permission-Claims. Welche Scopes/Roles sind im Token? Stimmen sie mit dem Erwartungswert überein?
Lehre und Schulung. Den Aufbau eines JWT anhand eines konkreten Beispiels demonstrieren.

JWT dekodieren ≠ verifizieren

Wichtig: Dekodieren bedeutet nicht, dass das Token authentisch ist. Jeder kann ein JWT mit beliebigem Inhalt erstellen — die Signatur garantiert nur, dass der Inhalt seit der Erzeugung nicht verändert wurde, und nur, wenn der Verifier den richtigen Schlüssel kennt. Unser Tool verifiziert die Signatur nicht (das würde den geheimen Schlüssel benötigen, den wir nicht haben sollten). Vertrauen Sie nie einem dekodierten JWT-Inhalt, ohne ihn auch verifiziert zu haben — auf dem Server, mit dem korrekten Schlüssel und Algorithmus.

Häufige Fragen

Wird das Token signaturgeprüft?

Nein. Unser Tool dekodiert die Base64url-kodierten Header- und Payload-Teile und zeigt sie lesbar an — die Signatur wird angezeigt, aber nicht kryptografisch verifiziert. Verifikation erfordert den Schlüssel, der das Token signiert hat (bei HS256 das gemeinsame Secret, bei RS256 der öffentliche Schlüssel). Diese Schlüsselverwaltung gehört in die serverseitige Anwendung, nicht in ein Web-Tool.

Was bedeutet "alg: none"?

Eine Sicherheitslücke. alg: none bedeutet "kein Algorithmus, keine Signatur erwartet" — eine historische Option in der JWT-Spezifikation. Bibliotheken, die das blindlings akzeptieren, lassen einen Angreifer beliebige Tokens fälschen. Moderne Bibliotheken lehnen none standardmäßig ab. Wir markieren ein solches Token rot als Warnung. Wenn Sie ein none-Token sehen, das auf einem Produktivsystem akzeptiert wurde, ist das ein kritischer Bug.

Wo werden meine Tokens gespeichert?

Nirgendwo. Alles passiert im Browser — wir senden keine Tokens an einen Server, protokollieren nichts, cachen nichts. Sie können sich nach dem Laden vom Internet trennen und das Tool weiterverwenden. Bedenken Sie jedoch: ein Token enthält oft sensible Claims (User-IDs, Permissions), behandeln Sie es wie ein Passwort.

Was sind Standard-Claims wie iat, exp, iss?

iat (issued at) — Unix-Timestamp der Token-Ausstellung. exp (expiration) — Unix-Timestamp des Ablaufs. iss (issuer) — wer das Token ausgestellt hat. sub (subject) — wem es gehört (typisch User-ID). aud (audience) — für welchen Empfänger es gedacht ist. jti (JWT ID) — eindeutige Token-ID zur Sperrung. nbf (not before) — frühestes gültiges Datum. Andere Claims sind anwendungsspezifisch.