JWT-Decoder kostenlos

Decodieren Sie JWT-Header, -Payload und -Claims lokal — mit optionaler HMAC-Signaturprüfung. Nichts verlässt Ihren Browser.

Der JWT-Decoder liest die JSON Web Tokens, die Ihre APIs ausstellen und verarbeiten — die kompakte header.payload.signature-Form, die OAuth 2.0, OpenID Connect und unzählige Auth-Bibliotheken verwenden — und zeigt sie als lesbares, formatiertes JSON: den Header mit Algorithmus und Schlüssel-ID, den Payload mit seinen Claims und das rohe Signatursegment. Die Decodierung läuft vollständig in Ihrem Browser: Base64url-Decodierung und JSON-Parsing sind lokal, sodass das Tool auch für Produktionstokens sicher ist, die echte Benutzerkennungen, E-Mails und Sitzungsdetails tragen — nichts wird hochgeladen, protokolliert oder gespeichert. Was dieser Decoder nicht tun wird, ist überversprechen. Er kann eine HMAC-Signatur prüfen, wenn Sie das Geheimnis einfügen: Das Tool berechnet den HMAC mit WebCrypto und meldet Signatur gültig oder Signatur ungültig, damit Sie bestätigen können, dass ein Token wirklich mit dem von Ihnen gehaltenen Geheimnis signiert wurde und unterwegs nicht manipuliert wurde. Diese Prüfung ist ehrlich über ihre Grenzen: Nur HS256, HS384 und HS512 lassen sich im Browser mit einem gemeinsamen Geheimnis verifizieren. Asymmetrische Tokens — RS256, ES256, PS256 und ihre Geschwister — sind in der Produktion die Norm, und ihre Verifikation erfordert den öffentlichen Schlüssel des Signierers, den ein clientseitiges Tool nicht für Sie besorgen kann; der Decoder sagt genau das, statt zu raten. Tokens mit alg=none, der berüchtigt unsicheren Konfiguration, werden als ungeschützt ohne Signatur markiert. Ablauf- und Ausstellungsclaims (exp, iat, nbf) erscheinen in ihrer rohen Epoch-Form im Payload-JSON, genau wie das Token sie trägt — das Tool konvertiert und interpretiert nicht, denn stille Konvertierung ist die Stelle, an der Decoder lügen. Fügen Sie ein Token aus Ihren Logs, Ihrem Netzwerkinspektor oder Ihren Tests ein und lesen Sie es, wie der Server es lesen würde.

Wird lokal in deinem Browser verarbeitet

Wie wird das Ergebnis berechnet?

Ein ID-Token aus Ihren Logs lesen

Die Zugriffslogs Ihres Dienstes enthalten ein Token wie das RFC-7515-Beispiel — ein Header mit HS256, ein Payload mit Subject, Name und Ausgabezeit sowie ein Signatursegment. Decodieren Sie es, um die Claims wie der Server zu lesen, und fügen Sie dann das gemeinsame Geheimnis ein, um zu bestätigen, dass die Signatur wirklich passt — ein manipuliertes sub oder ein abgelaufenes iat erscheint als Signatur ungültig.

Beispieleingabe und -ausgabe
Eingabe	Wert
Token	`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`
HMAC-Geheimnis (optional)	`your-256-bit-secret`
Ergebnis	{"sub":"1234567890","name":"John Doe","iat":1516239022} — Signatur gültig

Wie lautet die Formel und ihre Annahmen?

JWT-Kompaktserialisierung

JWT = base64url(Header) + "." + base64url(Payload) + "." + base64url(Signatur)

Formelbegriffe
Symbol	Bedeutung
`Header`	das JSON-Headerfeld: alg, typ und oft kid — Signaturalgorithmus und Schlüssel-ID
`Payload`	die JSON-Claims: registrierte (sub, iat, exp, nbf, iss, aud) plus benutzerdefinierte Claims
`base64url`	base64 mit URL-sicheren Zeichen (- und _) und ohne Padding

RFC 7519 §3.1. Das Tool decodiert die Segmente per base64url und formatiert das JSON; es sortiert oder interpretiert Claims nie um.

HMAC-Signaturverifikation

gültig = verify(HMAC-{SHA-256|384|512}(Geheimnis), base64url(header.payload), Signatur)

Formelbegriffe
Symbol	Bedeutung
`Geheimnis`	das von Ihnen eingefügte gemeinsame HMAC-Geheimnis — nur im Browser verwendet, nie gesendet
`base64url(header.payload)`	die Signatur-Eingabe: die ersten beiden Segmente exakt wie das Token sie trägt
`Signatur`	das dritte Segment, dekodiert zu den rohen MAC-Bytes

crypto.subtle.verify führt einen Vergleich in konstanter Zeit durch, sodass ein Missmatch nie Timing leakt. Asymmetrische Algorithmen benötigen den öffentlichen Schlüssel des Signierers und werden als lokal nicht verifizierbar gemeldet.

Welche Fehler sind am häufigsten?

Einem Token nur deshalb vertrauen, weil es sich decodieren lässt — Decodierung zeigt die Claims, nicht den Signierer; nur eine gültige Signaturprüfung belegt die Herkunft, und nur für HMAC-Tokens mit dem richtigen Geheimnis.
Annehmen, alg=none-Tokens seien „harmlos zu decodieren" — sie sind unsigniert und müssen von jeder Bibliothek, die sie akzeptiert, abgelehnt werden.
Produktionstokens in Online-Decoder einfügen, die sie hochladen — dieses Tool ist vollständig lokal; viele Webdienste behalten Ihr Token und Ihre Claims.

Welche Annahmen und Grenzen gelten?

Die Signaturprüfung deckt nur HMAC (HS256/384/512) ab — asymmetrische Tokens werden als lokal nicht verifizierbar gemeldet.
Claims werden roh angezeigt (Epoch-Sekunden für exp/iat/nbf); das Tool konvertiert sie nicht.
Opaque Access Tokens sind keine JWTs und lassen sich nicht decodieren.

Woher stammen die Zahlen?

Zuletzt geprüft 12. August 2026 · Version 1.0.0 · Toolivaro garantiert keine externen Inhalte.

Häufig gestellte Fragen

Wird mein Token irgendwohin hochgeladen?

Nein. Decodierung und Signaturprüfung laufen vollständig in Ihrem Browser mit WebCrypto — mit Ihrem Token oder Geheimnis wird keine Netzwerkanfrage gestellt. Das macht das Tool auch für Produktionstokens mit echten Benutzer-Claims sicher.

Warum können Sie RS256-Tokens nicht verifizieren?

RS256 und die anderen asymmetrischen Familien werden mit dem öffentlichen Schlüssel des Signierers verifiziert, der am JWKS-Endpunkt des Ausstellers liegt — ein clientseitiges Tool hat keine vertrauenswürdige Möglichkeit, diesen Schlüssel für Sie zu holen und zu vertrauen. Der Decoder meldet solche Tokens als lokal nicht verifizierbar, statt ein Ergebnis zu erfinden. HMAC-Tokens (HS256/384/512) brauchen nur das gemeinsame Geheimnis, deshalb werden sie geprüft, sobald Sie es angeben.

Was bedeutet es, wenn ein Token alg=none sagt?

alg=none erklärt, dass das Token überhaupt nicht signiert wurde. Bibliotheken, die none akzeptieren, sind die Quelle berüchtigter Authentifizierungs-Bypasses. Der Decoder markiert solche Tokens als ungeschützt, ohne Signatursegment zum Prüfen.

Warum werden exp und iat als rohe Zahlen angezeigt?

Weil das Token sie genau so trägt — NumericDate-Epoch-Sekunden nach RFC 7519. Das Tool konvertiert oder interpretiert Claims nicht stillschweigend: stille Konvertierung ist die Stelle, an der Decoder lügen, und der rohe Wert ist die Wahrheit, die der Server sieht.

Kann dieses Tool OAuth-2.0-Zugriffstokens decodieren?

Nur wenn es JWTs sind. Viele Anbieter (Okta, Auth0, Azure AD) stellen JWT-Zugriffstokens aus, und die lassen sich hier decodieren. Opaque Tokens — Zufallszeichenketten, die nur Identifikatoren sind — enthalten kein JSON und sind keine JWTs; kein Decoder kann daraus Claims machen.

Teil von Passwort-, Hash- und Sicherheits-Tools

Fehler gefunden oder eine Korrektur? Melde ihn — jede Korrektur wird geprüft.

War dieses Werkzeug hilfreich?

Überprüft vom Toolivaro-Redaktionsteam gemäß unserer Methodik Methodik · Redaktionsrichtlinie