JWT Debugger

JWT Debugger (Decodieren & Verifizieren)

JWT-Token online debuggen. Header- und Payload-Claims decodieren, HS256-, RS256- und ES256-Signaturen verifizieren und Ablaufzeiten lokal im Browser prüfen.

Voreinstellungen:
Codierter JWT-Token
Header (JOSE)(74B)
.
Payload (Claims)(248B)
.
Signatur (Krypto)(342B)
PKCS#1 / X.509 SPKI
Clock-Skew-Toleranz:
60s
Length: 666 charsSegments: 3/3
Header (JOSE) • Payload (Claims) • Signatur (Krypto)
Expiration (exp): 244d ago
Decodierter Header (JOSE)alg: RS256
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth0-key-2026-prod"
}
Decodierte Payload (Registrierte & Private Claims)6 registered & custom claims
{
  "iss": "https://auth.example.com/",
  "sub": "auth0|64f1a2b3c4d5e6f7",
  "aud": "https://api.example.com/v2/",
  "iat": 1772500000,
  "exp": 1772586400,
  "scope": "read:profile write:reports openid email"
}
iss (Issuer): https://auth.example.com/
sub (Subject): auth0|64f1a2b3c4d5e6f7
aud (Audience): "https://api.example.com/v2/"
iat (Issued At): 245d ago
Status:UNVERIFIED|Time: 0ms
Token-Größe666 B
AlgorithmusRS256
AblaufstatusToken abgelaufen
Sicherheitszustand85/100
SignaturstatusSchlüssel oder PEM zur Verifizierung eingeben
Anzahl der Claims6 Claims

Client-seitige Verarbeitung

Hochleistungsberechnung vollständig im lokalen Arbeitsspeicher des Browsers ausgeführt.

Kein Server-Upload & Privatsphäre

Alle Payloads verbleiben streng lokal – ohne jegliche Kommunikation mit externen Servern.

Produktionsreifer Export

Saubere, optimierte Ausgabeformate, bereit für den sofortigen Produktiveinsatz.

ToolsAA•100% Client-seitige private Web-Dienstprogramme
Technische Referenz & Architektur-Leitfaden

JWT Debugger (Decodieren & Prüfen) — Referenzhandbuch

JWT-Tokens direkt im Browser debuggen und analysieren: Header und Payload-Claims decodieren, HS256-, RS256- sowie ES256-Signaturen prüfen und Ablaufzeiten lokal validieren.

JWT Debugger (Decodieren & Prüfen) — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss
JWT Debugger (Decodieren & Prüfen) — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss

Wichtige Parameter & Einstellungen

JOSE-Header (JavaScript Object Signing and Encryption)JSON-Objekt (RFC 7515 JWS-Spezifikation)

Definiert den kryptografischen Algorithmus ('alg': HS256, RS256, ES256) und den Token-Typ ('typ': 'JWT'). Zur Abwehr von Algorithmen-Verwechslungsangriffen (Algorithm Confusion Attacks) müssen Verifizierer strikte Allowlisten erzwingen. Das Parsen erfolgt in linearer Laufzeit O(n) ohne Regex-Backtracking.

Standard: {"alg":"HS256","typ":"JWT"}
JWT-Claims-Payload (RFC 7519 Nutzdaten)JSON-Objekt (RFC 7519 Spezifikation)

Enthält Identitätsbehauptungen, Entitäts-Metadaten und Autorisierungsberechtigungen (Scopes). Standardisierte registrierte Claims umfassen 'sub' (Subject), 'iss' (Issuer), 'aud' (Audience), 'iat' (Ausstellungszeitpunkt) und 'exp' (Ablaufzeitpunkt in POSIX-Epochensekunden). Die lokale Web Crypto API Sandbox decodiert Claims in O(n)-Zeit ohne externe Netzwerkübertragung.

Standard: {"sub":"user_123","iat":1772500000,"exp":1772503600}
Kompakte JWS-SignaturKryptografischer Base64URL-Digest

Kryptografischer Digest, der durch Signieren von 'Base64URL(Header) + "." + Base64URL(Payload)' mit dem privaten Schlüssel oder Shared Secret erzeugt wird. Verifiziert die Authentizität und Datenintegrität mittels zeitkonstantem Vergleich (Constant-Time Comparison) zum Schutz vor Timing-Seitenkanalangriffen.

Standard: Base64URL-kodierte HMAC- oder RSA-Signatur
Gemeinsames HMAC-Secret / Öffentlicher PEM-SchlüsselKryptografisches Schlüsselmaterial (SPKI-PEM / Roh-Secret)

Kryptografischer Schlüssel zur Signaturverifikation. HS256 erfordert ein mindestens 256 Bit (32 Byte) langes Secret zum Schutz vor Offline-Wörterbuch- und Brute-Force-Angriffen; RS256 benötigt einen öffentlichen 2048-Bit- oder 4096-Bit-RSA-SPKI-PEM-Schlüssel; ES256 erfordert einen über die Web Crypto API mit crypto.subtle.importKey() importierten P-256-Schlüssel (secp256r1).

Standard: your-256-bit-secret
Zeittoleranz bei Taktversatz (Clock-Skew-Leeway)Zeitliches Toleranzfenster (Sekunden)

Zulässige zeitliche Abweichung (Standardintervall: 30 bis 120 Sekunden, Referenzwert: 60 Sekunden) zum Ausgleich von NTP-Uhrzeitdrift (Network Time Protocol) zwischen Authentifizierungsserver und verifizierendem Ressourcenserver bei der Validierung der Claims 'exp' und 'nbf'.

Standard: 60 Sekunden

Profi-Tipps & Best Practices

Niemals allein auf clientseitiges JWT-Decodieren vertrauen (Signatur am Ressourcenserver prüfen)

Das Decodieren eines JWT via Base64URL im Frontend-JavaScript ermöglicht zwar das Auslesen von Claims zur Personalisierung der Benutzeroberfläche (z. B. Benutzername anzeigen), bietet jedoch keinerlei Authentizitätsgarantie. Angreifer können Payload-Claims wie 'role: admin' im Browser in Sekundenschnelle manipulieren. Produktive API-Gateways und Backend-Dienste müssen die JWS-Signatur vor jeder Autorisierung kryptografisch mit einem vertrauenswürdigen Secret oder öffentlichen Schlüssel verifizieren.

Abwehr der 'alg: none'-Bypass-Schwachstelle (RFC 8725 §3.1)

RFC 7519 erlaubt für ungesicherte Kontexte formal ein Token mit 'alg: none'. Fehlerhafte Verifizierungsbibliotheken akzeptieren solche Tokens mit leerem Signaturblock, wodurch Angreifer beliebige Berechtigungen fälschen können. Konfigurieren Sie Ihre JWT-Middleware stets mit einer expliziten Algorithmen-Allowlist (z. B. algorithms: ['RS256']) und verwerfen Sie eingehende Tokens strikt, wenn 'alg' den Wert 'none' aufweist oder vom erwarteten Chiffrierverfahren abweicht.

256-Bit-Mindestentropie für HS256-Secrets strikt durchsetzen (RFC 7518 §3.2)

Symmetrische HMAC-Signaturen sind nur so sicher wie das zugrundeliegende Shared Secret. Falls ein HS256-Passwort aus gängigen Wörtern besteht oder kürzer als 32 Bytes (256 Bit) ist, können Offline-Cracking-Tools wie Hashcat das Secret anhand abgefangener Tokens in Sekunden rekonstruieren. Verwenden Sie kryptografisch sichere 256-Bit-Zufallsschlüssel, die mittels 'crypto.getRandomValues(new Uint8Array(32))' oder einem CSPRNG generiert wurden.

Key-Confusion-Angriffe zwischen symmetrischen und asymmetrischen Verfahren verhindern (RFC 8725 §3.2)

Bei einem Algorithmen-Verwechslungsangriff (Key Confusion) manipuliert ein Angreifer den Header eines RS256-Tokens auf 'HS256' und signiert ihn mit dem öffentlichen RSA-Schlüssel des Servers als HMAC-Secret. Prüft die Backend-Bibliothek den Schlüsseltyp nicht strikt, wird das gefälschte Token als legitim eingestuft. Schützen Sie sich davor, indem Sie pro Endpunkt feste Algorithmen vorgeben (Algorithm Pinning) und HMAC- sowie RSA-Schlüsselspeicher physisch und logisch strikt trennen.

JWT-Nutzdaten sind Base64URL-kodiert, NICHT verschlüsselt (Keine Passwörter oder PII speichern)

Ein herkömmliches JWT ist eine digital signierte JWS (JSON Web Signature) und keine verschlüsselte JWE (JSON Web Encryption). Der Payload ist lediglich Base64URL-kodiert und kann von jedem im Netzwerkverkehr oder über die Browser-Konsole im Klartext eingesehen werden. Speichern Sie niemals Datenbank-Zugangsdaten, Passwörter, Sozialversicherungsnummern oder vertrauliche Finanzdaten in JWT-Claims.

Häufige Fehlerquellen & Fehlerbehebung

⚠️Fehler 'Ungültige Signatur' (SignatureVerificationException) trotz scheinbar korrektem Secret

Dieser Fehler tritt häufig auf, wenn das Secret auf dem Authentifizierungsserver (z. B. Supabase oder Auth0) Base64-kodiert vorliegt, im Debugger jedoch als roher UTF-8-Klartext eingegeben wird. Aktivieren Sie die Option 'Base64 Secret', wenn Ihr Schlüssel Base64-kodiert ist. Prüfen Sie zudem, ob versehentlich Zeilenumbrüche ('\n'), Leerzeichen oder Anführungszeichen mit in das Eingabefeld kopiert wurden.

⚠️Fehler 'Token abgelaufen' (TokenExpiredError: jwt expired) unmittelbar nach Ausstellung

Die JWT-Claims 'exp' und 'iat' verlangen Sekunden seit der Unix-Epoche (10 Stellen) und keine Millisekunden (13 Stellen). Setzt Ihr Backend fälschlicherweise 'exp: Date.now()', liegt der Zeitstempel entweder weit in der Zukunft oder bei fehlerhafter Rundung im Jahr 1970. Verwenden Sie 'Math.floor(Date.now() / 1000) + lebensdauerInSekunden' und konfigurieren Sie auf dem Verifizierer eine Leeway-Toleranz von 60 Sekunden.

⚠️RS256-Prüfung schlägt mit 'Invalid Key Format' oder SPKI-PEM-Fehler fehl

RS256 verlangt einen öffentlichen Schlüssel im SubjectPublicKeyInfo-Format (SPKI-PEM), der mit '-----BEGIN PUBLIC KEY-----' beginnt und mit '-----END PUBLIC KEY-----' schließt. Falls Sie ein PKCS#1-Zertifikat mit '-----BEGIN RSA PUBLIC KEY-----' oder Daten eines JWKS-Endpunkts nutzen, konvertieren Sie den Schlüssel ins standardisierte SPKI-Format oder extrahieren Sie die x5c-Zertifikatskette in eine gültige PEM-Hülle.

⚠️Fehler 'Token fehlerhaft' (Malformed Token): JWT enthält nicht exakt zwei Trennpunkte

Ein valides kompaktes JWT nach RFC 7519 besteht aus exakt zwei Trennpunkten, die drei Base64URL-Segmente (Header.Payload.Signatur) separieren. Entfernen Sie beim Kopieren aus HTTP-Headern vor dem Parsen führende 'Bearer '-Präfixe, URL-kodierte Punkte ('%2E') sowie unsichtbare Zeilenumbrüche ('\r\n').

Häufig gestellte Fragen (FAQ)

Wie wird eine JWT-Signatur kryptografisch verifiziert und welche Rechenschritte sind erforderlich?▼

Zur Verifikation werden der originale Base64URL-kodierte Header und Payload mit einem Punkt verbunden ('header.payload'). Anschließend wird der kryptografische Prüfwert anhand des im Header definierten Algorithmus ('alg') und des Serverschlüssels berechnet und mit der Base64URL-decodierten Signatur verglichen. Bei HS256 geschieht dies über HMAC-SHA256 mit dem Shared Secret, bei RS256 über RSA-SHA256 mit dem öffentlichen Schlüssel des Ausstellers.

Worin liegt der Unterschied zwischen HS256 und RS256 bei der JWT-Authentifizierung?▼

HS256 ist ein symmetrisches Verfahren: Derselbe geheime Schlüssel wird sowohl zum Signieren als auch zum Verifizieren verwendet – ideal für geschlossene Architekturen, in denen Issuer und API-Gateway dieselbe Sicherheitszone teilen. RS256 ist ein asymmetrisches Verfahren: Der Authentifizierungsserver signiert mit einem privaten Schlüssel, während beliebig viele Ressourcenserver oder Drittanbieter die Signatur über das öffentliche Zertifikat verifizieren können, ohne dass der Signaturschlüssel offengelegt werden muss.

Kann ein JWT manipuliert oder verändert werden, ohne dass die Signatur ungültig wird?▼

Nein. Jede Änderung am Header oder am Payload – etwa das Hochstufen einer Benutzerrolle von 'user' auf 'admin' oder das Vorverlegen des Ablaufdatums – verändert die kryptografische Eingabe. Ohne den privaten Signaturschlüssel oder das geheime Shared Secret kann kein Angreifer eine passende Signatur erzeugen. Jeder standardkonforme Verifizierer weist das manipulierte Token unverzüglich wegen ungültiger Signatur ab.

Warum dürfen vertrauliche Daten wie Passwörter oder Kreditkartennummern niemals im JWT-Payload stehen?▼

Weil Standard-JWTs lediglich digital signiert (JWS) und nicht verschlüsselt (JWE) sind. Die Base64URL-Kodierung der Nutzdaten dient nur dem Transport und bietet keinerlei Vertraulichkeit. Jeder, der das Token im Netzwerkverkehr abfängt oder aus dem Browser-Speicher (LocalStorage/SessionStorage) ausliest, kann den Payload unmittelbar decodieren und alle enthaltenen Claims im Klartext einsehen.

Was sind registrierte JWT-Claims und welche Bedeutung haben iat, exp und nbf?▼

Registrierte Claims sind durch den Standard RFC 7519 vordefinierte Metadatenfelder: 'iat' (Issued At) bezeichnet den Ausstellungszeitpunkt als Unix-Timestamp; 'exp' (Expiration Time) definiert den Zeitpunkt, ab dem das Token ungültig ist; 'nbf' (Not Before) bestimmt, ab wann das Token frühestens gültig wird; 'iss' (Issuer) identifiziert den Aussteller; 'sub' (Subject) steht für die Benutzer- oder Entitäts-ID; und 'aud' (Audience) spezifiziert die berechtigten Ziel-Empfänger.

Verwandte Tools & Hilfsprogramme

Alle Tools →
CSP-GeneratorSicherheit

Sichere Content Security Policy (CSP) Header direkt generieren. script-src, style-src, Nonces und Hashes konfigurieren, um XSS-Angriffe abzuwehren und CSP-Fehler zu beheben.

Tool öffnen→
Bcrypt-Hash-Generator & Passwort-PrüferSicherheit

Erzeugen Sie kryptografisch sichere Eksblowfish-Passwort-Hashes mit anpassbaren Salt-Runden (4-16) und überprüfen Sie Passwörter lokal im Browser.

Tool öffnen→
HMAC-Signatur-Generator & Timing-Safe VerifiziererSicherheit

Berechnen und überprüfen Sie RFC 2104-konforme HMAC-Signaturen (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, HMAC-MD5) mit sicherem Timing-Safe-Abgleich lokal im Browser.

Tool öffnen→
Client-seitiges AES-GCM / CBC Verschlüsselungs- & Entschlüsselungs-ToolSicherheit

Hardwarebeschleunigte authentifizierte AES-256-Verschlüsselung direkt im Browser via Web Crypto API. Null Server-Speicherung.

Tool öffnen→
RSA Schlüsselpaar-Generator (Public & Private Key)Sicherheit

Erzeugen Sie kryptografisch sichere RSA-Schlüsselpaare (2048, 4096 Bit) im PKCS#8 PEM-Format direkt im Browser mit der Web Crypto API.

Tool öffnen→
Base58- & Base58Check-Kodierer / DekodiererSicherheit

Konvertieren Sie Text und Hexadezimalwerte in das von Bitcoin und IPFS genutzte Base58-Format mit SHA-256-Prüfsummen-Validierung.

Tool öffnen→