Decodieren, verifizieren und signieren Sie JSON Web Tokens in Ihrem Browser.

Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Credential aus drei base64url-Teilen, die durch Punkte getrennt sind: einem Header, einem Payload mit Claims und einer Signatur — geschrieben als header.payload.signature. Der Header benennt den Signaturalgorithmus, der Payload trägt Claims wie etwa, für wen der Token bestimmt ist und wann er abläuft, und die Signatur erlaubt es dem Empfänger zu bestätigen, dass der Token von einer vertrauenswürdigen Partei ausgestellt und nicht manipuliert wurde. JWTs werden in OAuth 2.0 und OpenID Connect verbreitet als Access- und ID-Token verwendet.

Nein. Das Decodieren und jede Signaturprüfung laufen zu 100 % clientseitig in Ihrem Tab — es gibt keinen Server, kein Konto, kein Logging und keinen Netzwerk-Request. Der Token, den Sie einfügen, und das Secret oder der Public Key, den Sie angeben, bleiben im Speicher dieser Seite und werden niemals hochgeladen. Sie können Token offline decodieren.

Ja, optional und lokal. Fügen Sie ein Shared Secret für einen HMAC-Token (HS256 / HS384 / HS512) oder einen Public Key für einen asymmetrischen Token ein — RS256–512, PS256–512, ES256–512 oder EdDSA — und das Tool berechnet die Signatur über die header.payload-Bytes mit der Web Crypto API direkt in Ihrem Browser neu und meldet dann gültig oder ungültig. Der Schlüssel kann ein PEM-Block ("BEGIN PUBLIC KEY"), ein einzelner JWK oder ein vollständiges JWKS sein (der passende Schlüssel wird über das kid im Header ausgewählt). Wenn Sie das Schlüsselfeld leer lassen, wird einfach decodiert, ohne die Signatur zu prüfen.

Ja. Wechseln Sie zum Tab "Encode & sign", bearbeiten Sie das Header- und Payload-JSON, wählen Sie einen Algorithmus und geben Sie ein Secret (für HS256/384/512) oder einen PKCS8-Private-Key bzw. privaten JWK (für RS, PS, ES oder EdDSA) an. Der Token wird live in Ihrem Browser mit der Web Crypto API signiert — nichts wird auf einem Server erzeugt. Es gibt außerdem einen Tab "Generate keys", der Test-HMAC-Secrets sowie RSA- / EC- / Ed25519-Schlüsselpaare erzeugt und sowohl als PEM als auch als JWK exportiert.

Alle dreizehn JWS-Signaturalgorithmen, die Browser nativ beherrschen: HS256, HS384 und HS512 (HMAC), RS256, RS384 und RS512 (RSASSA-PKCS1-v1_5), PS256, PS384 und PS512 (RSA-PSS), ES256, ES384 und ES512 (ECDSA auf P-256, P-384 und P-521) sowie EdDSA (Ed25519, in Browsern, die es unterstützen). Unsignierte alg:"none"-Token werden decodiert — mit einer Warnung — aber hier niemals erstellt, und ES256K (secp256k1) ist in der Web Crypto API nicht verfügbar.

Für Entwicklung und Tests ja: Die Schlüssel stammen aus dem kryptografisch sicheren Generator der Web Crypto API, werden vollständig auf Ihrem Rechner erzeugt und von dieser Seite niemals übertragen oder gespeichert. Für die Produktion sollten Sie Schlüssel stattdessen im KMS, HSM oder Secret Manager Ihrer Plattform generieren und aufbewahren — ein Browser-Tab bietet keine sichere Schlüsselaufbewahrung, und alles, was auf dem Bildschirm dargestellt wird, kann in Screenshots oder im Verlauf der Zwischenablage landen.

Es sind standardmäßige registrierte Claims, die als NumericDate (Sekunden seit der Unix-Epoche) ausgedrückt werden. exp (expiration time) ist der Zeitpunkt, nach dem der Token abgelehnt werden muss; nbf (not before) ist der Zeitpunkt, vor dem er nicht akzeptiert werden darf; iat (issued at) ist der Zeitpunkt, zu dem der Token erstellt wurde. Der Decoder wandelt jeden in eine lesbare UTC-Zeit um und kennzeichnet, ob der Token derzeit abgelaufen oder noch nicht gültig ist.

Das Decodieren findet ausschließlich in Ihrem Browser statt, es wird also nichts übertragen — aber ein JWT ist trotzdem ein aktives Credential. Behandeln Sie ihn wie ein Passwort: Fügen Sie nur einen Token ein, über den Sie die Kontrolle haben, bevorzugen Sie einen kurzlebigen oder Test-Token, und denken Sie daran, dass der Payload lediglich base64url-codiert und nicht verschlüsselt ist, sodass jeder, der den Token besitzt, dessen Claims lesen kann. Rotieren oder widerrufen Sie einen Token, wenn Sie vermuten, dass er irgendwo offengelegt wurde. Diese Vorsicht gilt doppelt für KI-Chatbots: Betrachten Sie jeden in ein Chat-Fenster eingefügten Token als offengelegt, und rotieren Sie ihn.

Standardmäßig signierte JWTs sind nicht verschlüsselt — der Header und der Payload sind nur base64url-codiert, sodass jeder, der den Token besitzt, dessen Claims ohne jeden Schlüssel lesen kann. Die Signatur belegt, dass der Token nicht manipuliert wurde, aber sie verbirgt den Inhalt nicht. Aus diesem Grund sollten Sie niemals Passwörter, personenbezogene Daten oder Secrets in JWT-Claims speichern.

Ja. Das Lesen von Header und Payload erfordert überhaupt keinen Schlüssel, da die Daten nur base64url-codiert sind. Das Secret oder der Public Key wird nur benötigt, um die Signatur zu verifizieren — um zu bestätigen, dass der Token wirklich vom erwarteten Aussteller stammt. Mit diesem Decoder können Sie die Claims inspizieren, ob Sie einen Schlüssel angeben oder nicht.

Fügen Sie den Token in den JWT Decoder ein und sehen Sie sich die Zeile mit dem exp-Claim an. Das Tool wandelt den rohen Unix-Zeitstempel in ein lesbares UTC-Datum um und kennzeichnet den Token automatisch als abgelaufen, wenn die aktuelle Zeit den exp-Wert überschritten hat. Die Claims iat (issued at) und nbf (not before) werden ebenfalls mit ihren menschenlesbaren Daten angezeigt.

Nein. Das Decodieren legt nur den Inhalt von Header und Payload offen — es belegt nicht, dass der Token authentisch ist. Um einen Token zu validieren, müssen Sie seine Signatur mit dem Secret oder dem Public Key des Ausstellers verifizieren. Dieses Tool kann diese Prüfung lokal im Browser durchführen, aber für Autorisierungsentscheidungen muss die Signatur immer serverseitig verifiziert werden, bevor man einem Claim vertraut.