JWT-Decoder

Diese beziehen sich auf den Signierungsalgorithmus im JWT-Header. HS256 (HMAC-SHA256) verwendet ein gemeinsames Geheimnis — derselbe Schlüssel wird zum Signieren und zum Verifizieren verwendet. Das bedeutet, dass jeder mit dem Schlüssel auch gültige Tokens erstellen kann. RS256 (RSA-SHA256) verwendet ein Public/Private-Key-Paar — der Server signiert mit einem privaten Schlüssel und veröffentlicht einen öffentlichen Schlüssel zur Verifizierung. RS256 ist in verteilten Systemen sicherer, da Verifizierer nur den öffentlichen Schlüssel benötigen und keine Token fälschen können. Dieser Decoder zeigt dir das alg-Feld an, kann aber keinen der Algorithmen verifizieren — er liest nur, was im Inneren steht.

Nein. Die Verifizierung der Signatur erfordert das Geheimnis (für HMAC-Algorithmen) oder den öffentlichen Schlüssel (für RSA/EC-Algorithmen), der zur Signierung des Tokens verwendet wurde. Dieses Tool dekodiert nur — es führt eine Base64url-Dekodierung des Headers und der Payload durch, um dir den Inhalt ohne kryptografische Verifizierung anzuzeigen. Der Signaturabschnitt wird unverändert angezeigt, aber nicht validiert. Für die Verifizierung der Signatur verwende deine serverseitige JWT-Bibliothek (jsonwebtoken für Node.js, PyJWT für Python, java-jwt für Java, etc.).

Registrierte Claims sind standardisierte Payload-Felder, die in RFC 7519 definiert sind. Die sieben Standard-Claims: iss (Issuer) — wer das Token ausgestellt hat; sub (Subject) — worum es bei dem Token geht (meist eine User ID); aud (Audience) — die beabsichtigten Empfänger; exp (Expiration Time) — Unix-Zeitstempel, nach dem das Token ungültig ist; nbf (Not Before) — Unix-Zeitstempel, vor dem das Token nicht akzeptiert werden darf; iat (Issued At) — Unix-Zeitstempel, wann das Token erstellt wurde; jti (JWT ID) — eindeutige Kennung für das Token. Dieses Tool konvertiert exp, nbf und iat von Unix-Zeitstempeln in menschenlesbare Daten.

Der Decoder prüft den exp-Claim gegen die aktuelle Zeit und markiert abgelaufene Token deutlich. Ein abgelaufenes Token bedeutet, dass die API es mit einer 401 Unauthorized-Antwort ablehnen wird — du musst deinen Refresh-Token verwenden, um ein neues Access-Token zu erhalten (falls dein Authentifizierungssystem Refresh-Token unterstützt) oder dich erneut anmelden. Wenn du einen "expired token"-Fehler von einer API debuggst, zeigt dir dieser Decoder genau an, wann das Token abgelaufen ist und wann es ausgestellt wurde.

Das alg-Feld im Header wird dekodiert angezeigt — wenn ein Token "alg":"none" hat, wirst du es sehen. Dies ist eine bekannte JWT-Schwachstelle: einige frühe Implementierungen akzeptierten Token ohne Signatur (alg:none), was es Angreifern ermöglichte, beliebige Payloads zu fälschen. Jede korrekt implementierte JWT-Bibliothek lehnt alg:none-Token standardmäßig ab. Wenn du alg:none in einem Token aus deinem eigenen System siehst, handelt es sich um einen kritischen Sicherheitsfehler, der sofort Aufmerksamkeit erfordert.

Nein. Die gesamte Dekodierung findet in deinem Browser mittels JavaScript statt — die Base64url-Dekodierung erfordert keine serverseitige Berechnung. Deine JWT-Token, einschließlich aller enthaltenen User IDs, Rollen oder Session-Daten, verlassen niemals dein Gerät. Dennoch solltest du vorsichtig sein, wenn du Produktions-JWT-Token in irgendein Online-Tool einfügst — auch in dieses hier. Verwende für das Debuggen von Produktions-Authentifizierungsproblemen stattdessen den Netzwerk-Tab der Entwicklertools deines Browsers oder dein Logging-System.

Ein gültiges JWT muss genau zwei Punkte haben, die drei Base64url-kodierte Abschnitte trennen. Wenn ein Token keine Punkte hat, ist es kein JWT — es könnte sich um ein opakes Token (eine Zufallsidentifikationsnummer, die eine serverseitige Suche erfordert) anstelle eines eigenständigen JWT handeln. Einige Systeme verwenden beide Typen: ein opakes Refresh-Token und ein JWT Access-Token. Wenn du eine "Invalid JWT format"-Fehlermeldung erhältst, überprüfe, ob du das Access-Token (das mit "ey" beginnen sollte) und nicht das Refresh-Token eingefügt hast.