stratdata

Wissen · Tool-Anleitungen

Ein JWT decodieren: was in einem JSON Web Token steckt

Header, Payload und Claims eines Tokens in Sekunden lesen — und verstehen, warum Lesen nicht Prüfen ist.

Wer im Browser die Entwicklerwerkzeuge öffnet, in einer Konfigurationsdatei stöbert oder ein Server-Log durchsieht, stösst früher oder später auf eine lange, kryptisch wirkende Zeichenkette, die mit eyJ… beginnt und zwei Punkte enthält. Das ist fast immer ein JSON Web Token (JWT) — der Ausweis, mit dem Login-Sitzungen und Schnittstellen (APIs) heute arbeiten. Die gute Nachricht für alle, die wissen wollen, was drinsteht: Man kann ein JWT-Token decodieren, ohne irgendein Passwort zu kennen. Der Inhalt ist nicht verschlüsselt, nur kodiert. Das ist praktisch beim Debuggen, beim Nachvollziehen, was ein Dienst über ein Konto speichert, und in der Recherche, wenn irgendwo ein Token auftaucht.

Was ist ein JWT — und warum kann man es einfach lesen?

Ein JWT besteht aus drei Teilen, die durch Punkte getrennt sind: Header, Payload und Signatur. Header und Payload sind je ein ganz gewöhnliches JSON-Objekt, das mit Base64url kodiert wurde — einer Umschrift, die Zeichen transportsicher macht, sie aber nicht geheim hält. Genau deshalb ist der Anfang eyJ so typisch: Das ist Base64 für die Zeichen {", mit denen jedes JSON-Objekt startet. Wer den Token hat, kann Header und Payload also im Klartext lesen.

Der dritte Teil, die Signatur, ist ein kryptografisches Siegel. Es beweist dem Server, dass der Token seit dem Ausstellen nicht verändert wurde und tatsächlich von ihm stammt. Dieses Siegel lässt sich aber nur mit dem geheimen Schlüssel des Ausstellers überprüfen — und ohne diesen Schlüssel sagt es einem Betrachter nichts über Echtheit oder Gültigkeit.

Ein Beispiel: das Token zerlegen

Der JWT-Decoder auf stratdata trennt den Token an den Punkten, dekodiert die beiden ersten Teile von Base64 zurück in JSON und stellt die einzelnen Angaben — die sogenannten Claims — lesbar dar. Für ein erfundenes Beispiel-Token sieht das so aus:

JWT — drei Teile, durch Punkte getrennt eyJhbGciOiJI…J9 . eyJpc3MiOiJh…MDB9 . Zx8kQ2m1…sT4u └─ Header ──┘ └─ Payload ─┘ └─ Signatur ┘ Header (Base64 → JSON) { "alg": "HS256", "typ": "JWT" } Payload (Base64 → JSON) ← jeder kann das lesen, es ist NICHT verschlüsselt { "iss": "auth.beispiel-shop.de" Aussteller (issuer) "sub": "user-8842" Subjekt / Konto-ID "name": "M. Beispiel" "role": "kunde" "iat": 1781532000 → 15.06.2026 14:00 UTC ausgestellt "exp": 1781535600 → 15.06.2026 15:00 UTC gültig bis — bereits abgelaufen } Signatur nicht geprüft — Dekodieren ist kein Verifizieren

Die Zahlen bei iat und exp sind Unix-Zeitstempel (Sekunden seit dem 1.1.1970). Der Decoder rechnet sie in ein lesbares Datum um. Hier fällt sofort etwas auf: Das Ablaufdatum exp liegt bereits in der Vergangenheit — dieses Token wäre also längst abgelaufen. Genau solche Kleinigkeiten macht das Zerlegen sichtbar.

Die üblichen Claims

Ein paar Namen sind in der JWT-Norm festgelegt und begegnen einem immer wieder:

Alles Weitere (name, role, E-Mail …) sind frei vergebene Zusatzfelder des jeweiligen Dienstes — nützlich, aber ohne feste Bedeutung.

Ein decodiertes Token ist ein Hinweis, kein Beweis. Dass im Payload "role":"admin" steht, heisst nicht, dass der Inhaber Administrator ist — der Server glaubt dem Token nur, wenn die Signatur gegen seinen geheimen Schlüssel aufgeht. Der Decoder prüft die Signatur nicht (er kann es ohne Schlüssel gar nicht) und sagt daher nichts über Echtheit oder aktuelle Gültigkeit. Zweitens: Ein gültiges, nicht abgelaufenes Token ist wie ein Passwort — wer es hat, kann sich als dieses Konto ausgeben. Behandeln Sie echte Tokens als Geheimnis, fügen Sie fremde oder produktive Tokens niemals in beliebige Online-Decoder ein, und decodieren Sie nur, was Sie einsehen dürfen. Der JWT-Decoder auf stratdata arbeitet dafür lokal im Browser — der Token verlässt Ihr Gerät nicht.

So gehen Sie vor

Mit dem KI-Agenten nutzen Alle Tools Mehr aus «Wissen»