Kostenloser JWT-Decoder Online

Der JWT-Decoder ist ein kostenloses Online-Tool, das JSON Web Tokens decodiert, um die Informationen aus Header, Payload und Signatur in einem lesbaren Format anzuzeigen.

Ja, er ist völlig kostenlos und erfordert keine Registrierung. Die gesamte Decodierung erfolgt clientseitig in Ihrem Browser, sodass Ihre Tokens niemals an einen Server gesendet werden.

Der JWT-Decoder zeigt den Algorithmus, den Token-Typ, die Ablaufzeit, den Aussteller, das Subjekt und alle benutzerdefinierten Claims an, die in der JWT-Payload gespeichert sind.

Absolut. Der JWT-Decoder verarbeitet alles clientseitig in Ihrem Browser. Es werden keine Daten auf einen Server hochgeladen oder dort gespeichert. Ihre Inhalte bleiben jederzeit privat auf Ihrem Gerät.

Ja, der JWT-Decoder ist vollständig responsiv und funktioniert auf Smartphones und Tablets. Sie können ihn auf jedem Gerät mit einem modernen Webbrowser nutzen, ohne eine App herunterladen zu müssen.

Es ist kein Konto und keine Registrierung erforderlich. Öffnen Sie einfach den JWT-Decoder in Ihrem Browser und legen Sie sofort los. Es gibt keine Anmeldeschranken oder Nutzungsbeschränkungen.

Geben Sie einfach Ihre Daten in das vorgesehene Feld ein, passen Sie die Einstellungen nach Wunsch an, und das Tool verarbeitet sie sofort. Anschließend können Sie das Ergebnis in die Zwischenablage kopieren oder herunterladen.

Der JWT-Decoder funktioniert in allen modernen Browsern, darunter Chrome, Firefox, Safari, Edge und Opera. Für das beste Erlebnis verwenden Sie die neueste Version Ihres bevorzugten Browsers.

Das Lesen eines JWT ist sicher, weil Header und Payload nur Base64URL-kodiert und nicht verschlüsselt sind — wer das Token besitzt, kann sie ohnehin dekodieren, sodass das Prüfen der Claims nichts offenbart, was geheim bleiben sollte. Das eigentliche Risiko liegt darin, wohin das Token übertragen wird: Ein aktives Access-Token ist ein gültiges Credential, weshalb das Einfügen in einen Dienst, der es an einen Server sendet, Ihre Sitzung gefährden könnte. Dieses Tool umgeht das vollständig, indem alles lokal in Ihrem Browser dekodiert wird; das Token wird niemals hochgeladen, protokolliert oder extern gespeichert. Zur Vorsicht sollten Sie nur Tokens dekodieren, zu deren Einsicht Sie berechtigt sind, ein aktives Token wie ein Passwort behandeln, das Sie nicht öffentlich teilen würden, und weder die URL noch einen Screenshot der dekodierten Payload weitergeben. Fügen Sie Ihr Token oben ein, um seine Claims sofort entschlüsselt zu sehen — vollständig clientseitig, ohne dass etwas Ihr Gerät verlässt.

Dekodieren und Verifizieren sind zwei getrennte Vorgänge. Beim Dekodieren werden Header und Payload lediglich Base64URL-dekodiert, damit Sie die Claims lesen können — es erfordert keinen Schlüssel und beweist nichts über die Echtheit. Verifizieren bedeutet, die Signatur mit dem Secret oder öffentlichen Schlüssel des Ausstellers neu zu berechnen und zu prüfen, ob sie übereinstimmt — nur so lässt sich feststellen, ob das Token nicht manipuliert oder gefälscht wurde. Dieser Decoder liest das Token und zeigt das rohe Signatursegment zur Referenz an, prüft es aber nicht kryptografisch. Behandeln Sie eine dekodierte Payload daher als reine Information, nicht als Beweis. Um tatsächlich zu verifizieren, benötigen Sie den Signaturschlüssel, der auf Ihrem Backend verbleiben sollte. Der Snippets-Tab bietet fertigen Code zum Verifizieren und Signieren für Node.js, Python, Go, Java, PHP und Ruby, damit Sie das Token in Ihrem eigenen Dienst korrekt validieren können.

Der Ablaufzeitpunkt steckt im Claim exp, einem Unix-Zeitstempel (Sekunden seit 1970), der den Moment markiert, ab dem das Token nicht mehr gültig ist. Zwei verwandte Claims legen das Zeitfenster fest: iat gibt an, wann das Token ausgestellt wurde, und nbf den frühesten Zeitpunkt, ab dem es genutzt werden darf. Rohe Zahlen sind schwer zu lesen, daher wandelt dieser Decoder exp, iat und nbf in gut lesbare Datumsangaben um und zeigt einen Live-Status, der angibt, ob das Token aktuell gültig, abgelaufen oder noch nicht aktiv ist. Dadurch werden „Warum bekomme ich einen 401?“-Fehler in Sekunden nachvollziehbar — ein abgelaufenes exp ist einer der häufigsten Gründe. Beachten Sie, dass diese Zeitstempel für jeden lesbar und bis zur Signaturprüfung unverifiziert sind und dass sie in UTC angegeben werden — berücksichtigen Sie also Ihre eigene Zeitzone beim Ablesen. Fügen Sie Ihr Token ein, um Ausstellungszeitpunkt, gültig-ab-Zeit und Ablaufzeit auf einen Blick als klare Datumsangaben dekodiert zu sehen.

Ein JWT besteht aus drei durch Punkte getrennten Teilen: header.payload.signature. Der Header beschreibt, wie das Token signiert ist — vor allem alg (Signaturalgorithmus, etwa HS256 oder RS256) und typ (Token-Typ). Die Payload enthält die Claims: Angaben zum Nutzer oder zur Sitzung wie iss (Aussteller), sub (Subjekt), aud (Zielgruppe/Audience), exp (Ablaufzeitpunkt) sowie beliebige benutzerdefinierte oder OIDC-Felder, die Ihr System hinzufügt. Die Signatur, berechnet aus Header und Payload mithilfe eines Schlüssels, ermöglicht einem Server zu prüfen, dass die beiden anderen Teile nicht verändert wurden. Dieser Decoder zerlegt das Token automatisch, kennzeichnet den Algorithmus als symmetrisch oder asymmetrisch und erklärt jeden registrierten Claim in klarer Sprache. Da Header und Payload lediglich kodiert sind, sollten dort niemals Passwörter oder Geheimnisse gespeichert werden. Fügen Sie oben ein Token ein, um Header und Claims getrennt und beschrieben zu sehen.

Ja — im Builder-Tab können Sie eine JWT-Struktur zu Testzwecken zusammenstellen. Wählen Sie einen Signaturalgorithmus, legen Sie eine Ablaufzeit in Minuten fest und fügen Sie eigene Claims hinzu — das Tool setzt daraus den passenden Header und die passende Payload zusammen. Entscheidend ist: Die Ausgabe ist bewusst unsigniert und enthält einen Platzhalter an der Stelle der eigentlichen Signatur, die Sie auf Ihrem Backend erzeugen. Das ist Absicht, denn das Signieren im Browser würde Ihr Secret offenlegen — ein symmetrischer HS256-Schlüssel etwa muss serverseitig bleiben, sonst könnte jeder, der den Seitenquelltext einsieht, gültige Tokens fälschen. Der Builder eignet sich daher hervorragend, um Token-Strukturen zu entwerfen, Claim-Sets zu prototypisieren oder Beispiel-Payloads für Dokumentationen zu erstellen — nicht jedoch, um Produktions-Credentials auszustellen. Wechseln Sie zum Builder-Tab, um eine Token-Struktur zu entwerfen, und signieren Sie sie anschließend sicher in Ihrem eigenen Dienst.