BrowserTools
Werbung
Startseite / Encoder / JWT-Decoder

JWT-Decoder

Dekodiere und untersuche JSON Web Tokens lokal: Header, Payload und Ablauf-Claims.

Betreut von BrowserTools · Zuletzt aktualisiert 2026-06-06

JWT-Decoder wird geladen… Wenn nichts passiert, aktiviere JavaScript.

Ein JSON Web Token (JWT) ist eine kompakte, URL-sichere Zeichenkette, die eine signierte Menge von Claims kodiert (Aussagen über einen Benutzer, eine Sitzung oder eine Berechtigung) in einem Format, das jede Partei mit dem richtigen Schlüssel unabhängig überprüfen kann. Definiert durch RFC 7519 (2015) und Teil der umfassenderen JOSE-Standardfamilie (Signierung und Verschlüsselung von JSON-Objekten), wurden JWTs schnell zum vorherrschenden Mechanismus für zustandslose Authentifizierung und API-Autorisierung in Web-, Mobil- und Microservice-Architekturen. Ein JWT besteht aus drei Base64url-kodierten Segmenten, getrennt durch Punkte: dem Header (Algorithmus-Metadaten), dem Payload (den Claims) und der Signatur.

Beispiele

Eingabe eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.<sig>
Ausgabe Header {"alg":"HS256","typ":"JWT"} · Payload {"sub":"1234567890","name":"John Doe"}

Ein JWT besteht aus drei Base64url-Teilen, durch Punkte verbunden: Header.Payload.Signatur.

Häufig gestellte Fragen

Wird mein Token an einen Server hochgeladen?
Nein. Die Dekodierung erfolgt vollständig in deinem Browser über die eingebaute JavaScript-Funktion atob und JSON.parse. Dein JWT, das Benutzeridentität, Berechtigungen oder Sitzungsdaten enthalten kann, verlässt nie dein Gerät und wird nie über das Netz gesendet.
Was sind die drei Teile eines JWT?
Ein JWT besteht aus drei Base64url-kodierten JSON-Objekten, getrennt durch Punkte. Der Header gibt den Tokentyp ('JWT') und den Signaturalgorithmus an (z. B. HS256, RS256). Der Payload enthält die Claims: Standardfelder wie iss (Aussteller), sub (Subjekt), exp (Ablauf), iat (ausgestellt am), plus beliebige anwendungseigene Claims. Die Signatur wird vom ausstellenden Server über Header und Payload berechnet und erlaubt es Empfängern zu prüfen, dass das Token nicht manipuliert wurde.
Wann sollte ich ein JWT in meiner eigenen Anwendung verwenden?
JWTs eignen sich ideal für zustandslose Authentifizierung: Einmal ausgestellt, muss der Server keinen Sitzungszustand speichern, das Token selbst trägt alles, was zur Autorisierung einer Anfrage nötig ist. Sie passen gut zu Microservices und APIs, bei denen mehrere Dienste die Identität prüfen müssen, ohne eine Sitzungsdatenbank zu teilen. Sie funktionieren gut für kurzlebige Zugriffstokens (Minuten bis Stunden). Für langlebige Sitzungen, bei denen du sofortige Sperrung brauchst, ist eine klassische serverseitige Sitzung mit Datenbankabfrage oft passender.
Wie unterscheidet sich ein JWT von einem Sitzungs-Cookie?
Ein Sitzungs-Cookie speichert eine zufällige, undurchsichtige Kennung; der Server schlägt die eigentlichen Sitzungsdaten bei jeder Anfrage in einer Datenbank nach. Ein JWT ist eigenständig: Der Server validiert die Signatur und liest die Claims aus dem Token selbst, ohne Datenbankabfrage. JWTs sind daher schneller und leichter horizontal skalierbar, aber schwerer zu widerrufen: Du kannst ein JWT vor seinem Ablauf nicht 'abmelden', es sei denn, du pflegst eine Token-Sperrliste, was wieder serverseitigen Zustand einführt.
Überprüft dieses Tool die JWT-Signatur?
Nein, und das bewusst. Die Signaturprüfung erfordert den geheimen Schlüssel des Ausstellers (bei HMAC-Algorithmen wie HS256) oder dessen öffentlichen Schlüssel (bei RSA/ECDSA-Algorithmen wie RS256). Du solltest niemals einen geheimen Schlüssel in ein Drittanbieter-Tool einfügen. Dieser Decoder zeigt dir die dekodierten Header- und Payload-Claims nur zu Inspektionszwecken. Für die Signaturprüfung in der Produktion verwende eine vertrauenswürdige Bibliothek in deiner eigenen Umgebung.
Was bedeuten die Standard-Zeitstempel-Claims?
iat (issued at) ist der Unix-Zeitstempel der Token-Erstellung. exp (expiration time) ist der Zeitstempel, nach dem das Token abgelehnt werden muss. nbf (not before) ist der Zeitstempel, vor dem das Token nicht akzeptiert werden darf. Alle drei sind Sekunden seit der Unix-Epoche (1. Januar 1970 UTC). Dieses Tool wandelt sie automatisch in lesbare Daten um, sodass du sofort siehst, ob ein Token abgelaufen oder noch nicht gültig ist.
Kann ein JWT ohne Signatur verwendet werden (alg: none)?
Die JWT-Spezifikation erlaubt technisch ein ungesichertes Token mit 'alg': 'none' und einer leeren Signatur. Solche Tokens in der Produktion zu akzeptieren ist jedoch eine kritische Sicherheitslücke. Mehrere frühe JWT-Bibliotheken vertrauten 'alg': 'none' standardmäßig und erlaubten Angreifern, beliebige Tokens zu fälschen. Konfiguriere deine JWT-Bibliothek stets so, dass sie einen bestimmten Algorithmus verlangt und Tokens mit 'alg': 'none' ablehnt, sofern du keinen sehr konkreten Grund hast, unsignierte Tokens zuzulassen.
Sind JWT-Payloads privat und vertraulich?
Nein. Ein Standard-JWT (JWS, JSON Web Signature) signiert den Payload, um die Integrität zu garantieren, verschlüsselt ihn aber nicht. Der Payload ist lediglich Base64url-kodiert, was jeder sofort dekodieren kann. Nimm niemals sensible Informationen (Passwörter, Kreditkartennummern, Ausweisnummern oder Daten, die du nicht offenlegen möchtest) in einen JWT-Payload auf. Wenn du verschlüsselte Tokens brauchst, verwende stattdessen JWE (JSON Web Encryption), das ein eigener Standard ist.
Was ist der Unterschied zwischen HS256 und RS256?
HS256 verwendet HMAC-SHA256: Derselbe geheime Schlüssel dient zum Signieren und Überprüfen des Tokens, was es zu einem symmetrischen Verfahren macht. Das ist einfach, bedeutet aber, dass jeder Dienst, der Tokens prüft, das Geheimnis kennen muss. RS256 verwendet RSA-SHA256: Der Aussteller signiert mit einem privaten Schlüssel, und jeder Dienst kann mit dem zugehörigen öffentlichen Schlüssel überprüfen. RS256 wird in Architekturen mit mehreren Diensten bevorzugt, weil öffentliche Schlüssel über einen JWKS-Endpunkt frei geteilt werden können, ohne das Signaturgeheimnis offenzulegen.
Was ist ein häufiger Fehler von Entwicklern bei JWTs?
Der häufigste Fehler ist, eine gültige Signatur als Berechtigungsnachweis zu behandeln, ohne auch den exp-Claim zu prüfen: Ein abgelaufenes Token mit gültiger Signatur sollte stets abgelehnt werden. Ein dicht darauf folgender Fehler ist, das JWT in localStorage statt in einem HttpOnly-Cookie zu speichern, wodurch es jedem JavaScript auf der Seite ausgesetzt ist (XSS-Angriffe). Eine dritte Falle ist, zu viele Daten in den JWT-Payload zu packen: Große Tokens fügen jeder Anfrage Latenz hinzu, weil sie in jedem HTTP-Header übertragen werden müssen.

Über JWT-Decoder

JWTs tauchen in praktisch jedem modernen Authentifizierungsablauf auf. OAuth-2.0-Zugriffstokens werden fast durchweg als JWTs ausgegeben. OpenID-Connect-ID-Tokens sind JWTs, die die Identitäts-Claims des authentifizierten Benutzers tragen. Single-Sign-on-Systeme reichen JWTs zwischen Identitäts- und Dienstanbietern weiter. Serverless-Funktionen und Edge-Worker validieren JWTs lokal ohne Datenbankabfrage und ermöglichen so zustandslose, horizontal skalierbare Authentifizierung. Mobile Apps speichern JWTs als Bearer-Tokens und fügen sie dem Authorization-Header jeder API-Anfrage bei. Zu verstehen, was in einem Token steckt (welche Berechtigungen es gewährt, wann es abläuft und wer es ausgestellt hat), ist eine tägliche Aufgabe für jeden Backend- oder Sicherheitsingenieur.

Dieses Tool dekodiert Header und Payload eines beliebigen JWT vollständig in deinem Browser. Es dekodiert jedes Segment per Base64url, parst das JSON und stellt die Claims in lesbarer Form dar. Numerische Zeitstempel (iat, exp, nbf) werden automatisch in lesbare Daten umgewandelt, sodass du sofort siehst, ob ein Token abgelaufen ist. Die Signatur wird unverändert angezeigt, aber bewusst nicht überprüft: Die Überprüfung erfordert das Geheimnis des Ausstellers (bei HMAC) oder dessen öffentlichen Schlüssel (bei RSA/ECDSA), und du solltest niemals eines davon in ein nicht vertrauenswürdiges Online-Tool einfügen. Da die Dekodierung lokal erfolgt, verlässt nicht einmal das Token selbst dein Gerät.

Einige Sicherheitspunkte zum Beachten: JWTs sind standardmäßig signiert, aber nicht verschlüsselt; der Payload ist lediglich Base64url-kodiert, was bedeutet, dass jeder, der das Token abfängt, dessen Claims lesen kann. Nimm niemals sensible personenbezogene Daten (Passwörter, Kreditkartennummern) in einen JWT-Payload auf. Der Angriff alg: none ist eine bekannte Schwachstelle in naiven JWT-Bibliotheken, die unsignierte Tokens akzeptieren; verwende stets eine gut geprüfte Bibliothek, die den Algorithmus explizit validiert. Prüfe außerdem den exp-Claim, bevor du einem Token vertraust: Eine gültige Signatur bedeutet nicht, dass das Token noch aktiv ist.

Der Aufstieg des JSON Web Token

JSON Web Tokens wurden von der Internet Engineering Task Force (IETF) im Rahmen der JOSE-Arbeitsgruppe (Signierung und Verschlüsselung von JSON-Objekten) eingeführt, mit dem im Mai 2015 veröffentlichten RFC 7519. Das Ziel war ein kompaktes, eigenständiges Anmeldeformat, das die ausführlichen und komplexen SAML-XML-Assertions ersetzen konnte, die in Single-Sign-on-Systemen von Unternehmen verwendet wurden. Das durch Punkte getrennte, Base64url-kodierte Design wurde bewusst gewählt, um URL-sicher zu sein und bequem in einen HTTP-Header zu passen.

Die Verbreitung war explosionsartig. Innerhalb weniger Jahre nach der Veröffentlichung hatte fast jedes große Authentifizierungs-Framework, von Auth0 über Firebase Authentication bis AWS Cognito, JWTs als Tokenformat standardisiert. Die Website jwt.io, von Auth0 als Debugging-Werkzeug gestartet, wurde zu einem der meistbesuchten Entwickler-Tools im Internet. Diese Popularität zog auch Prüfung an: Sicherheitsforscher katalogisierten eine Reihe von Implementierungsschwachstellen (den 'alg: none'-Fehler, Algorithmus-Verwechslungsangriffe), die naive Bibliotheksimplementierungen betrafen, und lösten eine Welle von Verbesserungen in JWT-Bibliotheken über alle Programmiersprachen hinweg aus.

Eine interessante Designentscheidung bei JWTs ist, dass der Payload für jeden lesbar ist: Die Signatur garantiert Integrität, aber keine Geheimhaltung. Das war Absicht: Die Entwickler wollten, dass Tokens ohne Schlüssel debugbar sind, damit Werkzeuge wie JWT-Decoder Entwicklern helfen, Tokens während der Entwicklung zu untersuchen. Der Kompromiss ist, dass Entwickler diszipliniert damit umgehen müssen, welche Claims sie aufnehmen, eine Lektion, die Teams auf die harte Tour lernten, als sie versehentlich JWTs mit sensiblen Benutzerdaten auslieferten.

Verwandte Tools

Base64-Encoder und -Decoder

Kodiere und dekodiere Text oder Dateien lokal in deinem Browser als Base64.

Hash-Generator (SHA-1, SHA-256, SHA-384, SHA-512)

Berechne kryptografische Hashes von Text oder Dateien lokal: SHA-1, SHA-256, SHA-384 und SHA-512.
Werbung
Werbung
Werbung