Dekodieren Sie JWT-Header und -Payload, prüfen Sie Claims und Ablaufzeit — ohne dass das Token Ihren Browser verlässt.
Ein JSON Web Token (JWT, RFC 7519) besteht aus drei Base64URL-kodierten Segmenten, getrennt durch Punkte: einem Header, der den Signaturalgorithmus benennt, einem Payload mit den Claims — wer das Token ausgestellt hat, für wen und bis wann es gültig ist — und einer Signatur. JWTs sind das Standard-Bearer-Credential von OAuth 2.0 und OpenID Connect — deshalb beginnt das Debugging eines Login-Flows oder einer API-Integration so oft mit der Frage: Was steckt eigentlich in diesem Token?
Dieser Decoder teilt das Token an den Punkten, stellt das Base64URL-Padding wieder her, dekodiert jedes Segment als UTF-8 und formatiert das JSON. Er hebt die registrierten Claims hervor — iss (Issuer), sub (Subject), aud (Audience), iat (Issued at), nbf (Not before) und exp (Expiration) — und wandelt die numerischen Zeitstempel, die Sekunden seit der Unix-Epoche zählen, in lesbare UTC-Daten um. Die Ablaufzeit wird zudem mit Ihrer Uhr verglichen, sodass der Status auf einen Blick zeigt, ob das Token noch gültig ist und wie lange — oder wie lange es schon abgelaufen ist. Fehlerhafte Eingaben erzeugen eine klare, freundliche Fehlermeldung statt einer kryptischen Exception.
Eines muss so laut wie möglich gesagt werden: Ein JWT zu dekodieren heißt nicht, es zu validieren. Header und Payload sind lediglich Base64URL-kodiert — jeder kann sie lesen und jeder kann sie fälschen. Nur die Signatur, geprüft gegen das Secret oder den öffentlichen Schlüssel des Ausstellers, beweist die Echtheit eines Tokens, und genau das tut dieses Tool bewusst nicht: Die Signaturprüfung gehört auf Ihren Server, mit einer richtigen JWT-Bibliothek. Aus demselben Grund gehören Passwörter oder andere Geheimnisse niemals in einen JWT-Payload — kodiert ist nicht verschlüsselt. Das hier eingefügte Token wird vollständig in Ihrem Browser dekodiert und nie übertragen; behandeln Sie Produktionstoken dennoch als die Zugangsdaten, die sie sind.
Nein — es dekodiert nur Header und Payload und sagt das bei jedem Ergebnis. Ein dekodiertes Token beweist nichts über seine Echtheit: Verifizieren Sie die Signatur auf Ihrem Server mit dem Schlüssel des Ausstellers und einer richtigen JWT-Bibliothek, bevor Sie einem Claim vertrauen.
Nein. In einem standardmäßig signierten JWT (JWS) sind Header und Payload nur Base64URL-kodiert und für jeden lesbar, der das Token besitzt. Verschlüsselte JWTs (JWE) existieren, sind aber selten; speichern Sie niemals Geheimnisse in einem normalen JWT-Payload.
Es sind Zeitstempel in Sekunden seit der Unix-Epoche: iat ist der Ausstellungszeitpunkt, nbf der Moment, vor dem das Token abgelehnt werden muss, und exp der Ablaufzeitpunkt. Dieses Tool wandelt alle drei in lesbare UTC-Daten um und berechnet den Ablaufstatus für Sie.
Die häufigsten Ursachen: Es wurde etwas eingefügt, das kein kompaktes JWT ist (es muss genau drei durch Punkte getrennte Teile haben), das Token wurde beim Kopieren abgeschnitten, oder es stehen zusätzliche Zeichen darum herum. Das "Bearer "-Präfix wird automatisch behandelt; alles andere um das Token herum nicht.
Nein. Die Dekodierung läuft zu 100% lokal in JavaScript — das Token wird nie übertragen, protokolliert oder gespeichert. Dennoch ist ein Produktions-JWT ein aktives Credential: Vermeiden Sie Screenshots davon und widerrufen Sie Token, deren Offenlegung Sie vermuten.
Vai.la verwandelt jede URL in einen Kurzlink mit Klick-Statistiken, QR-Code und Ihrem eigenen Biolink.
Vai.la übernimmt keine Verantwortung für die Nutzung der Tools oder für Entscheidungen, die auf ihren Ergebnissen basieren.