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.
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.