Dekodiere jeden JSON Web Token, um Header, Payload und Signatur zu sehen — oder signiere einen neuen mit HS256/384/512. Verifiziert HMAC-Signaturen lokal. Komplett im Browser.
Dekodiere jeden JSON Web Token, um Header, Payload und Signatur zu sehen — oder signiere einen neuen mit HS256/384/512. Verifiziert HMAC-Signaturen lokal. Komplett im Browser.
Nein. Das gesamte Tool ist JavaScript innerhalb dieser Seite. Du fügst ein Token ein, die Dekodierung erfolgt in deinem Browser, die Bytes verlassen den Tab nie. Öffne DevTools → Network und schau zu — beim Dekodieren oder Verifizieren werden keine Anfragen gesendet. Damit ist es sicher, echte Kunden- oder Produktions-Token einzufügen.
Sie beweist, dass das Token von jemandem signiert wurde, der das Secret (HMAC) oder den privaten Schlüssel (RSA/ECDSA) besitzt. Sie verschlüsselt den Payload NICHT — Header und Payload sind nur base64url-kodiertes JSON, jeder mit dem Token kann sie lesen. Die Signatur verhindert nur Manipulation: Wenn du ein einziges Byte des Payloads änderst, passt die Signatur nicht mehr.
Ein JWT trägt oft die Benutzer-ID, E-Mail, Scopes und manchmal das Äquivalent von Session-Cookies — genau die Daten, die du NICHT in den Server eines Fremden einfügen darfst. Der Decoder von iKit läuft als JavaScript, das bereits in deinem Browser-Tab geladen ist. Überprüfbar in DevTools → Network: kein fetch, kein XHR, kein beacon beim Dekodieren oder Verifizieren.
Für HS256/384/512-Token gib das Signing-Secret ein, um die Signatur lokal zu verifizieren. Für RS256/ES256 (RSA/ECDSA) verwende eine serverseitige Bibliothek — die Public-Key-Verifizierung benötigt eine PEM-Datei, die wir hier nicht akzeptieren.
HS256 benötigt mindestens 32 Bytes (256 Bit) für echte kryptografische Stärke. Zum Testen funktioniert alles, aber in der Produktion sollte ein langes zufälliges Secret verwendet werden.
Der schnellste Weg, ein JWT zu debuggen — kein Upload, keine Anmeldung, keine Drittpartei zwischen dir und deinem Token.
Füge ein JWT ein und sieh den dekodierten Header, Payload und die Signatur nebeneinander. Standard-Claims (iss, sub, aud, exp, iat) werden mit Zeitstempel und Beschriftung angezeigt.
Für HS256/384/512-Token gib das Secret ein, um die Signatur mit der Web Crypto API des Browsers zu verifizieren. Das Secret verlässt deinen Tab nie.
Wechsle in den Encode-Modus, bearbeite Header und Payload als JSON, wähle den Algorithmus, gib ein Secret ein und erhalte sofort ein signiertes Token.
JWT-Payloads enthalten Benutzer-IDs, E-Mails, manchmal Scopes — niemals in ein Server-Tool einfügen. Der Decoder von iKit läuft als JavaScript in deinem Browser. Überprüfbar in DevTools → Network.
Standard-Claims wie exp, nbf, iat werden mit menschenlesbaren Daten und einem klaren ABGELAUFEN/gültig-Badge hervorgehoben, sodass du auf einen Blick siehst, ob das Token noch gültig ist.
Basiert auf der nativen Web Crypto API und dem JSON-Parser des Browsers — dieselben Algorithmen wie OpenSSL, libjwt, jose. Das Verhalten entspricht jeder modernen JWT-Bibliothek.
Ein JWT besteht aus drei base64url-kodierten JSON-Segmenten, getrennt durch Punkte — mehr nicht.
Ein JWT sieht so aus: aaa.bbb.ccc. Wir teilen an den zwei wörtlichen Punkten und erhalten den kodierten Header, Payload und die Signatur. Erhalten wir nicht genau drei Teile, ist das Token fehlerhaft.
Header und Payload sind base64url-kodiertes UTF-8-JSON. Base64URL = Base64 mit -/_ statt +//= und ohne Padding. Wir machen atob, nachdem die Zeichen zurückersetzt wurden, und JSON.parse den resultierenden String.
Der Header verrät uns den Algorithmus (alg: HS256, RS256, etc.) und den Typ. Der Payload enthält die Claims — Standard-Claims (iss, sub, aud, exp, iat, nbf, jti) plus beliebige eigene Felder. Wir zeigen jeden in einem beschrifteten Bereich an.
Für HS256/384/512 berechnen wir den HMAC von header.payload mit dem eingegebenen Secret neu und vergleichen ihn mit der Signatur im dritten Segment. Entspricht HMAC(SHA-256, secret, signing_input) base64url-kodiert. Übereinstimmung = Signatur gültig.
Reale Situationen, in denen du zu einem JWT-Decoder greifst.
Auth0, Firebase, Keycloak, AWS Cognito geben nach dem Login alle JWTs zurück. Füge das access_token ein, um zu sehen, welche Claims deine App tatsächlich erhält — was ist die Benutzer-ID, welche Scopes, wann läuft es ab?
API lehnt deine Anfrage ab? Dekodiere das Token und prüfe: Ist es abgelaufen (exp in der Vergangenheit)? Ist der Audience-Claim (aud) das, was die API erwartet? Ist der Issuer (iss) der richtige Tenant?
Stripe, GitHub Apps, Slack senden Webhook-Payloads als JWTs signiert. Nach dem Empfang füge es im Decode-Modus zusammen mit dem geteilten Secret ein, um zu bestätigen, dass die Anfrage tatsächlich von ihnen stammt.
Brauchst du ein frisches signiertes JWT für einen Integrationstest? Wechsle in den Encode-Modus, bearbeite den Payload (eigene Benutzer-ID, eigene Ablaufzeit), wähle HS256 + dein Test-Secret und erhalte ein Token in Millisekunden. Ohne Backend-Roundtrip.
Ein JWT trägt oft die Benutzer-ID, E-Mail, Scopes und manchmal das Äquivalent von Session-Cookies — genau die Daten, die du NICHT in den Server eines Fremden einfügen darfst. Der Decoder von iKit läuft als JavaScript, das bereits in deinem Browser-Tab geladen ist. Überprüfbar in DevTools → Network: kein fetch, kein XHR, kein beacon beim Dekodieren oder Verifizieren.
Ausführliche Tutorials und Tool-Vergleiche aus dem iKit-Blog.
JWT segments are base64url-encoded JSON — understand the encoding before you debug a token.
JWT signatures are HMAC-SHA hashes — the same family of cryptographic hashes used to verify file integrity.
Nein. Das gesamte Tool ist JavaScript innerhalb dieser Seite. Du fügst ein Token ein, die Dekodierung erfolgt in deinem Browser, die Bytes verlassen den Tab nie. Öffne DevTools → Network und schau zu — beim Dekodieren oder Verifizieren werden keine Anfragen gesendet. Damit ist es sicher, echte Kunden- oder Produktions-Token einzufügen.
Sie beweist, dass das Token von jemandem signiert wurde, der das Secret (HMAC) oder den privaten Schlüssel (RSA/ECDSA) besitzt. Sie verschlüsselt den Payload NICHT — Header und Payload sind nur base64url-kodiertes JSON, jeder mit dem Token kann sie lesen. Die Signatur verhindert nur Manipulation: Wenn du ein einziges Byte des Payloads änderst, passt die Signatur nicht mehr.
Drei häufige Ursachen: (1) falsches Secret — JWT-Secrets unterscheiden zwischen Groß- und Kleinschreibung und jede Leerzeichen-Abweichung bricht die Verifizierung. (2) Algorithmus-Diskrepanz — der Header sagt HS256, aber das Secret wurde ursprünglich mit HS512 verwendet. (3) Token wurde nach dem Signieren verändert — schon ein Byte bricht die Signatur. Prüfe, ob header.alg dem entspricht, was du erwartest.
iKit unterstützt derzeit nur HMAC-Verifizierung (HS256/384/512). RS256 und ES256 verwenden Public-Key-Kryptografie — die Verifizierung benötigt den öffentlichen Schlüssel des Ausstellers im PEM-Format, was eine aufwändigere UI bedeutet. Vorerst funktioniert das Dekodieren weiterhin (Header/Payload/Signatur werden korrekt angezeigt), aber der Verifizieren-Button meldet, dass es nicht unterstützt wird. RSA/ECDSA-Verifizierung ist geplant.
Gleiche Idee, andere Standardeinstellungen. Der Decoder von iKit läuft komplett in deinem Browser (jwt.io tut das auch, aber iKits Code ist über View-Source einsehbar und unsere Domain hat keine Drittanbieter-Tracker). Wir ergänzen ein klares ABGELAUFEN/gültig-Badge für den exp-Claim, strukturierte Claim-Hinweise (iat / nbf / iss / sub / aud / jti als lesbare Zeilen) und einen Button zum Kopieren der gesamten dekodierten Ausgabe als strukturierter Output für Bug-Reports.