JWT Decoder online – JSON Web Tokens schnell dekodieren
JWT Decoder
JSON Web Tokens sofort dekodieren, Header, Payload und Signatur analysieren, Ablaufzeiten prüfen und alle Claims verstehen. Kein Token verlässt deinen Browser. Jetzt mit Signatur-Verifikation, Export-Funktion und erklärendem JWT-Guide.
Füge deinen JWT-Token unten ein. Das Token bleibt vollständig in deinem Browser — es wird nirgendwo übertragen oder gespeichert.
Für HS256/HS384/HS512: Gib den geheimen Schlüssel ein, um die Signatur zu prüfen. Der Schlüssel verlässt niemals deinen Browser.
Der vollständige JWT-Guide — von Einsteiger bis Experte
Dieser Guide erklärt JSON Web Tokens von Grund auf: Was ist ein JWT, wie ist es aufgebaut, wie wird es in echten Anwendungen eingesetzt, welche Sicherheitsrisiken gibt es — und wie benutzt du diesen Decoder optimal? Springe direkt zum Level, das zu deinem Wissensstand passt.
Was ist ein JWT? (Extrem einfach erklärt)
Stell dir vor, du gehst auf ein Konzert. An der Kasse kaufst du ein Ticket. Auf diesem Ticket stehen dein Name, der Bereich (Stehplatz, VIP), die Gültigkeit (nur heute) und eine eindeutige Ticketnummer. Der Türsteher kann das Ticket prüfen, ohne nochmal die Kasse fragen zu müssen — er vertraut dem Ticket selbst.
Das Konzert-Ticket = JWT. Das Ticket enthält alle nötigen Infos (Name, Bereich, Gültigkeit) — genau wie ein JWT alle Nutzerdaten enthält.
Die Kasse = Auth-Server. Die Kasse stellt das Ticket aus und signiert es (mit einem Stempel, der nur die Kasse kennt) — wie ein Server ein JWT erstellt.
Der Türsteher = API / Backend. Der Türsteher prüft das Ticket, ohne die Kasse anrufen zu müssen — genau wie ein Server ein JWT prüft, ohne die Datenbank zu befragen.
Der Stempel = Signatur. Das Hologramm auf dem Ticket verhindert Fälschungen — die kryptografische Signatur des JWT macht dasselbe.
Ein JWT (JSON Web Token) ist also: ein kleines, selbstenthaltendes "Ausweis-Dokument", das beweist wer du bist und was du darfst — ausgestellt von einem Server, prüfbar von jedem, der den richtigen Schlüssel kennt.
Warum braucht man JWTs überhaupt?
Das Web ist von Natur aus zustandslos — jede HTTP-Anfrage ist vergesslich. Wenn du auf eine Website einloggst und dann auf eine andere Seite navigierst, weiß der Server nicht mehr, wer du bist. Früher speicherte der Server eine "Session" in seiner Datenbank ("Nutzer 1234 ist eingeloggt") — das skaliert aber schlecht bei Millionen von Nutzern.
JWTs lösen dieses Problem: Alle relevanten Infos stecken im Token selbst. Der Server muss nichts speichern — er liest einfach das Token und vertraut ihm (nach Signaturprüfung).
Aufbau eines JWT — die drei Teile
Ein JWT sieht aus wie drei kryptische Zeichenketten, getrennt durch Punkte. Jeder Teil ist Base64url-kodiert:
// So sieht ein JWT aus:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← Header (blau)
.
eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbm5hIiwiZXhwIjoxNzAwMDAwMDAwfQ ← Payload (lila)
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← Signatur (grün)Was ist Base64url — und warum "kein Verschlüsseln"?
Base64url ist ein Kodierungsverfahren — wie das Übersetzen von Deutsch in Morse-Code. Es verändert die Darstellung, nicht den Inhalt. Jeder kann Base64url dekodieren — auch ohne Schlüssel. Ein JWT ist also nicht geheim! Header und Payload sind für jeden lesbar, der das Token hat.
Kodierung vs. Verschlüsselung — der Unterschied
- Kodierung (Base64url): Umwandlung für sichere Übertragung. Umkehrbar ohne Schlüssel. Schützt vor Zeichenkodierungs-Problemen in URLs. Schützt nicht vor unbefugtem Lesen.
- Verschlüsselung (AES, RSA…): Macht Daten für alle außer dem Schlüsselinhaber unlesbar. Schützt den Inhalt aktiv.
- Signatur (HMAC, RSA-Sig…): Prüft ob Daten manipuliert wurden. Macht Daten nicht unlesbar, verhindert aber unbemerkte Änderungen.
👉 Ein JWT ohne Verschlüsselung schützt nicht den Inhalt. Es schützt nur vor Manipulation. Speichere niemals Passwörter oder sensible Daten im JWT-Payload!
Die drei Teile im Detail
1. Header — Algorithmus und Typ
Der Header sagt dem Empfänger: "Wie wurde dieses Token signiert?" Typisch sieht er so aus:
{
"alg": "HS256", // Algorithmus: HMAC SHA-256
"typ": "JWT" // Token-Typ
}2. Payload — Die Claims (Nutzdaten)
Der Payload enthält die eigentlichen Informationen — die sogenannten Claims. Claims sind Aussagen über den Nutzer oder das Token selbst:
{
"sub": "user_123", // Subject: Wer ist das?
"name": "Anna Müller", // Name (OpenID Connect)
"email": "anna@beispiel.de", // E-Mail
"role": "admin", // Custom Claim: Rolle
"iat": 1700000000, // Issued At (Unix Timestamp)
"exp": 1700086400 // Expiration: läuft ab
}Timestamps wie iat und exp sind Unix-Timestamps — Sekunden seit 1.1.1970. Unser JWT Decoder wandelt sie automatisch in lesbares Datum/Uhrzeit um.
3. Signatur — Der Echtheitsbeweis
Die Signatur wird aus Header + Payload berechnet und verhindert Manipulation. Bei HS256 sieht die Berechnung so aus:
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
geheimer_schlüssel // Nur der Server kennt ihn!
)Die Signatur kann nicht dekodiert werden — das ist kein Base64, sondern ein echter kryptografischer Hash. Sie beweist nur: "Dieser Header + Payload wurde mit dem richtigen Schlüssel signiert."
Claims im Detail — Standard und Custom
Es gibt drei Arten von JWT Claims:
Registrierte Claims (RFC 7519 — empfohlen)
iss(Issuer) — Aussteller des Tokens. Z.B.https://auth.meine-app.desub(Subject) — Subjekt/Nutzer, für den das Token gilt. Meist die User-ID.aud(Audience) — Für welche Anwendung ist es gedacht? Z.B.api.meine-app.deexp(Expiration Time) — Ablaufzeitpunkt — Unix-Timestamp. Token danach ungültig.nbf(Not Before) — Gültig erst ab diesem Zeitpunkt.iat(Issued At) — Ausstellungszeitpunkt — nützlich für Debugging.jti(JWT ID) — Eindeutige ID — für Token-Blacklists und Replay-Prevention.
Öffentliche Claims (OpenID Connect Standard)
Von Diensten wie Google, Microsoft, Auth0 standardmäßig verwendet:
name— Vollständiger Nameemail— E-Mail-Adresseemail_verified— Ob die E-Mail bestätigt wurdepicture— URL zum Profilbildgiven_name/family_name— Vor- und Nachnamelocale— Spracheinstellung (z.B.de-DE)
Private / Custom Claims (deine Anwendung)
role/roles— Benutzerrolle für RBACpermissions— Granulare Rechtetenant_id— Mandantenkennung (Multi-Tenant-Apps)plan— Subscription-Level (free, pro, enterprise)org_id— Organisationskennung
Wie JWT in APIs eingesetzt wird
Login-Request
Nutzer sendet Credentials: POST /auth/login { email, password }
Server prüft und erstellt JWT
Bei erfolgreicher Authentifizierung signiert der Auth-Server ein JWT mit allen relevanten Claims und gibt es zurück.
Client speichert das Token
Speicherorte: localStorage, sessionStorage oder ein HttpOnly Cookie (sicherste Option für Web-Apps).
Authentifizierte API-Anfragen
Jede Anfrage trägt das Token im Authorization-Header: Authorization: Bearer eyJhbGci...
Server verifiziert Signatur + Claims
Der Server prüft die Signatur, ob exp abgelaufen ist, ob aud stimmt — ohne Datenbankabfrage.
Zugriff gewährt
Bei gültigem Token wird die Anfrage verarbeitet. Die Claims (z.B. role) steuern die Berechtigungen.
Reale Use Cases — JWT in der Praxis
Login & Session Management
Nach dem Login erhält der Nutzer ein kurzlebiges Access-Token (15 Min) und ein langlebiges Refresh-Token (7 Tage). Das Access-Token wird bei jeder API-Anfrage mitgeschickt.
Häufigster Use CaseMicroservices-Kommunikation
Service A ruft Service B auf und übergibt das JWT. Service B kann den Nutzer und seine Rechte aus dem Token lesen — ohne gemeinsame Session-Datenbank.
Backend-ArchitekturRole-Based Access Control (RBAC)
Das JWT enthält role: "admin" oder permissions: ["read", "write", "delete"]. API-Endpoints prüfen diese Claims direkt im Token — kein DB-Lookup nötig.
OAuth 2.0 / OpenID Connect
Dienste wie Google, Microsoft, Auth0 oder Keycloak geben JWTs als ID-Token und Access-Token aus. Unser Decoder zeigt alle enthaltenen OIDC-Claims direkt erklärt an.
Identity ProviderMobile App Authentifizierung
Apps speichern JWTs im Secure Storage des Geräts (Keychain/Keystore). Das Token wird bei App-Start validiert — ohne erneuten Login.
iOS & AndroidServerless & Edge Functions
Bei AWS Lambda, Cloudflare Workers oder Vercel Edge Functions gibt es keinen shared State. JWTs ermöglichen stateless Auth direkt in der Edge-Funktion.
Cloud-nativSignatur-Algorithmen im Vergleich
🔑 HMAC (HS256 / HS384 / HS512)
- Einfach zu implementieren
- Sehr schnell
- Gut für monolithische Apps
- Symmetrisch: ein gemeinsamer Schlüssel
- Schlüssel muss geteilt werden
- Schlecht für verteilte Systeme
🔐 RSA/ECDSA (RS256 / ES256)
- Asymmetrisch: privat signieren, öffentlich prüfen
- Ideal für Microservices
- Public Key kann geteilt werden (JWKS)
- Langsamer (RSA besonders)
- Komplexere Infrastruktur
- ECDSA: sichererer für gleiches Schutzniveau
Empfehlung: Für neue Projekte RS256 oder ES256 bevorzugen — asymmetrische Signaturen ermöglichen es, Public Keys öffentlich zu teilen (über JWKS-Endpoint), ohne das Signaturgeheimnis zu exponieren. HS256 nur in monolithischen Setups mit sicher geschütztem Secret.
Stateless Authentication — das Kernprinzip
Das revolutionäre an JWT: Der Server muss keinen Zustand speichern. Ein Datenbankserver mit 100.000 aktiven Sessions wird schnell zum Bottleneck. Mit JWTs kannst du theoretisch unbegrenzt skalieren — jeder Server kann jedes Token prüfen, solange er den Public Key kennt.
Der Preis: JWTs können nicht widerrufen werden, bevor sie ablaufen (außer mit einer Blacklist-Datenbank — was den Stateless-Vorteil aufhebt). Lösung: Kurze Laufzeiten (exp maximal 15 Minuten) + Refresh-Token-Mechanismus.
JWT Security Guide — Kritische Risiken und Lösungen
Manche alten JWT-Bibliotheken akzeptierten Tokens mit "alg":"none" — ohne Signaturprüfung. Ein Angreifer konnte beliebige Claims einfügen. Lösung: Immer den erwarteten Algorithmus explizit prüfen, none ablehnen.
HS256 mit kurzen Schlüsseln (z.B. secret123) ist anfällig für Brute-Force. Ein gutes HMAC-Secret sollte ≥256 Bit (32 Bytes) zufällig sein. Mit openssl rand -base64 32 generierbar.
Passwörter, Kreditkartennummern, private Keys, SSNs — nichts davon gehört in einen JWT! Der Payload ist Base64, kein Geheimnis. Nur nicht-sensible Identifikations- und Autorisierungsdaten speichern.
Ohne aud-Validierung könnte ein Token, das für Service A ausgestellt wurde, auch bei Service B funktionieren. Immer aud im Token setzen und serverseitig prüfen.
Gestohlene Tokens aus localStorage können bis zum exp verwendet werden. Lösung: Kurze Laufzeiten, HttpOnly-Cookies statt localStorage, jti-Claim für Blacklisting kritischer Tokens.
Access-Token sollten maximal 15–60 Minuten gültig sein. Refresh-Tokens (7–30 Tage) sollten beim Server invalidierbar sein. Nie Access-Tokens mit Laufzeiten von Tagen oder Wochen ausstellen.
- Access-Token: max. 15 Minuten
exp - HttpOnly-Cookies statt localStorage für Web-Apps
- RS256 oder ES256 für Microservices
- Immer
iss,aud,expserverseitig validieren - HTTPS erzwingen — JWTs dürfen nie unverschlüsselt übertragen werden
- HMAC-Secrets: min. 256 Bit, kryptografisch zufällig
alg:nonein JWT-Bibliothek explizit deaktivieren- Keine sensiblen Daten im Payload
JWT vs. Sessions — Was ist besser?
✅ JWT Vorteile
- Stateless — kein Session-Storage
- Skaliert horizontal ohne Shared State
- Ideal für Microservices & APIs
- Funktioniert domain-übergreifend (CORS)
- Self-contained — alle Infos im Token
⚠️ JWT Nachteile
- Nicht revokierbar (vor exp)
- Größer als Session-Cookie (Overhead)
- Claims werden nicht automatisch aktualisiert
- Mehr Komplexität für Entwickler
- Schwieriger zu debuggen
Wann JWT nicht verwenden: Für einfache Web-Apps mit einem einzigen Backend sind klassische Sessions (HttpOnly-Cookie + serverseitige Session) oft sicherer und einfacher. JWT glänzt bei verteilten Systemen, APIs und Mobile-Apps.
Häufige Fehler beim JWT-Einsatz
Diese Fehler sehen wir bei Code-Reviews immer wieder:
- JWT für Sessions verwenden ohne Logout-Lösung: Bei einem kompromittierten Token gibt es ohne Blacklist keine Möglichkeit zum Logout vor Token-Ablauf.
- Client-seitig dekodierten Daten vertrauen: Der Client kann Base64 selbst dekodieren. Verwende nur serverseitig verifizierte Token-Daten für Sicherheitsentscheidungen.
- Signatur nicht prüfen: Manche Bibliotheken haben einen "nur dekodieren"-Modus. Niemals für Authentifizierung nutzen — immer Signatur verifizieren!
- Refresh-Token in localStorage: localStorage ist XSS-anfällig. Refresh-Tokens (die langen!) gehören in HttpOnly-Cookies.
- Keine Claims-Validierung: Nur die Signatur prüfen reicht nicht. Auch
exp,iss,aud,nbfmüssen validiert werden.
Decoder-Guide: So benutzt du dieses Tool optimal
Token einfügen
Kopiere dein JWT und füge es im Textfeld ein. Die Dekodierung startet sofort automatisch beim Tippen.
Farbige Vorschau lesen
Sieh sofort welcher Teil Header (blau), Payload (lila) oder Signatur (grün) ist.
Statusanzeige prüfen
Der grüne/gelbe/rote Statusbalken zeigt sofort: Ist das Token noch gültig? Wann läuft es ab?
Claims-Tabelle lesen
Alle Claims werden erklärt angezeigt. Timestamps werden automatisch in lesbares Deutsch umgewandelt. Sensible Felder werden markiert.
Optionale Signaturprüfung
Für HS256/HS384/HS512-Token: Gib den geheimen Schlüssel ein, um die Signatur direkt im Browser zu verifizieren. Der Schlüssel verlässt niemals deinen Computer.
Exportieren & Teilen
Exportiere den dekodierten Payload als JSON oder CSV. Erstelle einen teilbaren Link mit dem Token (nur für Debug-Zwecke!).
JWT-Bibliotheken und Frameworks
Fast jede Sprache hat ausgereifte JWT-Bibliotheken. Immer eine gut gepflegte, weit verbreitete Bibliothek verwenden — niemals JWT manuell implementieren:
Empfohlene JWT-Bibliotheken nach Sprache
- JavaScript/Node.js:
jose(modern, TS-first),jsonwebtoken(weit verbreitet) - Python:
python-jose,PyJWT - Java / Kotlin:
nimbus-jose-jwt,jjwt - Go:
golang-jwt/jwt - PHP:
firebase/php-jwt,lcobucci/jwt - C# / .NET:
System.IdentityModel.Tokens.Jwt - Ruby:
ruby-jwt - Rust:
jsonwebtokencrate
Wenn du in Logs oder Texten nach JWTs suchst, hilft unser Regex Tester mit dem Muster eyJ[A-Za-z0-9\-_]+\.eyJ[A-Za-z0-9\-_]+\.[A-Za-z0-9\-_]+. Um Timestamps zu konvertieren, nutze unseren Unix Timestamp Konverter, und für API-Responses eignet sich der JSON Formatter. Token-Teile lassen sich mit dem Base64 Decoder manuell dekodieren.
OpenID Connect und OAuth 2.0 im Überblick
Die meisten JWT-Tokens, denen du begegnest, kommen aus OpenID Connect (OIDC) oder OAuth 2.0:
- ID Token (OIDC): Beantwortet "Wer ist dieser Nutzer?" — enthält Name, E-Mail, Profilbild. Wird vom Client gelesen, nicht an APIs weitergegeben.
- Access Token (OAuth 2.0): Beantwortet "Was darf dieser Nutzer?" — enthält Scopes, Rollen, Audience. Wird im Authorization-Header an APIs geschickt.
- Refresh Token: Kein JWT, sondern ein opaker String. Damit wird ein neues Access Token geholt, wenn das alte abläuft.
Dienste wie Google, Microsoft Azure AD, Auth0, Keycloak, Firebase Auth und Okta verwenden alle dieses Muster. Unser Decoder erkennt OIDC-Standard-Claims automatisch und erklärt sie in der Claims-Tabelle.
Datenschutz
Dieser JWT Decoder arbeitet vollständig lokal in deinem Browser. Kein einziges Zeichen deines Tokens wird an externe Server gesendet, gespeichert oder protokolliert. Die gesamte Base64url-Dekodierung, JSON-Verarbeitung und optionale HMAC-Verifikation findet clientseitig in JavaScript statt.
Das gilt für alle Tools auf Werkix: Auch der Passwort Generator, der Hash Generator und der Base64 Encoder verarbeiten alle Daten lokal. Dennoch gilt: Füge keine Produktions-Tokens mit echten Nutzerdaten in Browser-Tools ein.
Häufige Fragen zum JWT Decoder
exp-Claim (Expiration Time als Unix-Timestamp). Sobald die aktuelle Uhrzeit diesen Wert überschreitet, gilt das Token als abgelaufen. Du siehst genau wann das Token abgelaufen ist, wenn du es hier dekodierst. Lösung: Ein neues Access-Token über den Refresh-Token-Mechanismus holen, oder sich erneut einloggen.exp prüfen (nicht abgelaufen). 3) nbf prüfen (gültigkeitsbeginn). 4) iss prüfen (richtiger Aussteller). 5) aud prüfen (richtiger Empfänger). Dieser Decoder prüft exp, nbf und optionale HMAC-Signatur direkt im Browser."alg":"none" hat keine kryptografische Signatur. Das ist eine massive Sicherheitslücke: Jeder kann beliebige Claims einsetzen. Seriöse JWT-Bibliotheken lehnen alg:none heute standardmäßig ab. Unser Decoder zeigt eine Warnung wenn diesen Algorithmus erkannt wird.exp im Decoder prüfen. (2) Falsche Audience — aud stimmt nicht mit der API überein. (3) Falscher Issuer — iss nicht konfiguriert. (4) Token falsch übermittelt — muss als Bearer TOKEN im Authorization-Header stehen. (5) Signatur ungültig — falscher Schlüssel auf dem Server..png)
