Entwickler 🔒 Läuft im Browser — keine Daten werden gesendet

JWT-Decoder

JSON Web Tokens lokal dekodieren und die Signatur mit Secret oder öffentlichem Schlüssel prüfen — nichts verlässt den Browser.

JWT-Token

Secret oder öffentlicher Schlüssel

Erwarteter Aussteller (iss) Erwartete Zielgruppe (aud)

Der Schlüssel wird in Ihrem Browser verwendet und nirgendwohin gesendet.

Dekodiert

Header

Payload

Signatur

Signieren Sie ein eigenes Token, um einen Endpunkt zu testen. Alles wird auf dieser Seite berechnet.

Algorithmus Läuft ab in Schlüssel-ID (optional)

Payload (JSON)

Signaturschlüssel Secret ist Base64

Signiertes Token

Schlüssel und fertiges Token bleiben in Ihrem Browser: Beides wird nirgendwohin gesendet und steht auch in keinem geteilten Link.

Prüfen Sie dieses Token in Ihrem eigenen Code. Das Snippet richtet sich nach dem Algorithmus im Header.

Sprache

Anleitung

1. Fügen Sie ein JWT (eine Zeichenfolge mit drei durch Punkte getrennten Teilen) in das Eingabefeld ein. Es wird schon beim Tippen dekodiert.
2. Lesen Sie Header und Payload als formatiertes JSON, dazu die Tabellen darunter, in denen jedes Feld mit seiner Bedeutung steht.
3. Die Zeile darüber sagt, ob das Token abgelaufen ist; exp, nbf und iat erscheinen als Daten in Ihrer eigenen Zeitzone.
4. Um die Signatur zu prüfen, fügen Sie das Secret oder den öffentlichen Schlüssel unter dem Token ein und klicken Sie auf „Prüfen“.

Alles läuft in Ihrem Browser; Token und Schlüssel werden nie an einen Server gesendet. Die Tabs unter dem Decoder können zweierlei mehr: „Token bauen“ signiert ein eigenes Token, und „Code“ zeigt die Prüfung für acht Programmiersprachen.

Häufige Fragen

Überprüft dieses Tool die Signatur des JWT?

Ja. Fügen Sie das Secret (für HS256, HS384 und HS512) oder den öffentlichen Schlüssel als PEM oder JWK (für die Verfahren RS, PS und ES) unter dem Token ein und klicken Sie auf „Prüfen“. Die Prüfung läuft über die WebCrypto-API Ihres Browsers, der Schlüssel verlässt die Seite also nie. Ein Token mit alg "none" wird abgelehnt, denn es trägt überhaupt keine Signatur. Bloßes Dekodieren beweist weiterhin nichts — es zeigt nur, was ein Token behauptet.

Ist es sicher, ein echtes JWT hier einzufügen?

Ja — das Dekodieren erfolgt vollständig in Ihrem Browser mit JavaScript; das Token wird niemals irgendwohin übertragen. Behandeln Sie Zugriffs-/ID-Token dennoch als vertraulich und fügen Sie Tokens nicht in Tools ein, denen Sie nicht vertrauen.

Warum kann ich den Payload ohne geheimen Schlüssel lesen?

JWTs sind signiert, nicht verschlüsselt (außer bei expliziter Verwendung von JWE). Jeder kann Header und Payload dekodieren — die Signatur beweist nur, dass das Token nicht manipuliert wurde, sofern Sie den Schlüssel zur Überprüfung haben.

Was bedeuten "exp", "iat" und "nbf"?

Das sind Standard-JWT-Claims: "iat" (issued at) ist der Zeitpunkt der Token-Erstellung, "exp" (expiration) ist der Zeitpunkt, ab dem es ungültig wird, und "nbf" (not before) ist der früheste Zeitpunkt, ab dem es gültig ist. Dieses Tool wandelt diese Unix-Zeitstempel automatisch in lesbare Daten um.

Was tun bei einem Dekodierungsfehler?

Stellen Sie sicher, dass Sie das vollständige Token mit allen drei Teilen (header.payload.signature) eingefügt haben und nichts abgeschnitten oder verändert wurde. Zusätzliche Leerzeichen oder Zeilenumbrüche können ebenfalls Fehler verursachen — versuchen Sie, diese zu entfernen.

Wie dekodiere ich einen JWT in Python oder JavaScript?

In JavaScript mit dem Paket jwt-decode: jwtDecode(token). In Python mit PyJWT: jwt.decode(token, options={"verify_signature": False}). Beide lesen die Payload ohne Prüfung; zum Verifizieren übergeben Sie den Schlüssel.

Woran erkenne ich, wann ein JWT abläuft?

Am Claim exp: ein Unix-Timestamp in Sekunden. Rechnen Sie ihn mit dem Timestamp-Konverter um und vergleichen Sie ihn mit der Serverzeit, nicht mit Ihrem Laptop – ein paar Minuten Uhrabweichung sind eine häufige Ursache für überraschende Abläufe.

Warum wird mein Token abgelehnt, obwohl er sich dekodieren lässt?

Prüfen Sie exp gegen die Serveruhr, dann aud und iss gegen die Erwartung der API. Eine falsche Audience ist die häufigste Ursache für ein 401 bei einem gültig wirkenden Token.

Kann ich hier auch ein Token erstellen?

Ja. Der Tab „Token bauen“ unter dem Decoder signiert ein Token mit jedem der zwölf Algorithmen – HS, RS, PS und ES in je drei Größen. Algorithmus wählen, Payload bearbeiten, das gemeinsame Secret oder einen privaten PKCS#8-Schlüssel einfügen und auf „Token signieren“ klicken. Signiert wird mit der WebCrypto-Funktion Ihres Browsers, der Schlüssel bleibt also auf der Seite.

JWT Decoder - JSON Web Token online dekodieren

Aktualisiert am 24. September 2026 · Von Saman

Fügen Sie ein JSON Web Token ein: Dieser Decoder zerlegt es in seine drei Teile und zeigt Header und Payload als lesbares JSON. Das ist der schnellste Weg zu den Fragen, die beim Debuggen einer Anmeldung auftauchen - wer hat das Token ausgestellt, für wen ist es gedacht, mit welchem Algorithmus wurde signiert, und ist es bereits abgelaufen?

Die Dekodierung läuft vollständig im Browser. Das ist hier wichtiger als bei den meisten Werkzeugen, denn ein JWT ist ein aktives Zugangsmittel: Wer ein gültiges Token abfängt, kann bis zum Ablauf meist im Namen des Subjekts handeln. Nichts, was Sie einfügen, wird hochgeladen, protokolliert oder gespeichert.

Ein JWT besteht aus drei Base64URL-Strings, die durch Punkte verbunden sind. Header und Payload sind einfaches JSON, das jeder dekodieren kann – ein Token darf also nie Geheimnisse enthalten. Erst die mit dem Schlüssel geprüfte Signatur zeigt, dass das Token nicht verändert wurde.

Was ist ein JSON Web Token?

Ein JWT besteht aus drei Base64URL-Segmenten, verbunden durch Punkte: header.payload.signature. Der Header nennt den Signaturalgorithmus, der Payload trägt die Claims - die Aussagen, die der Aussteller über Nutzer oder Client trifft - und die Signatur belegt, dass die ersten beiden Teile von jemandem mit dem passenden Schlüssel stammen. Header und Payload sind nur kodiert, nicht verschlüsselt, also für jeden lesbar. Geschützt ist allein die Signatur.

JWT hier dekodieren

Token aus dem Authorization: Bearer-Header, einem Cookie, einer Callback-URL oder Ihrem API-Client kopieren.
Die vollständige Zeichenkette header.payload.signature in das Eingabefeld einfügen.
Auf Dekodieren klicken, um beide JSON-Objekte nebeneinander zu sehen.
Bei abgelehnten Requests zuerst exp prüfen, danach aud und iss.

Was die Seite sonst noch kann

Das Token wird beim Tippen gelesen, die Bereiche füllen sich also, bevor Sie zur Schaltfläche greifen. Unter dem dekodierten Header und Payload steht jedes Feld in einer Tabelle, mit seiner Bedeutung in einfachen Worten, und eine Zeile darüber macht aus exp und nbf ganze Sätze: vor drei Tagen abgelaufen, läuft in achtundfünfzig Minuten ab, noch nicht gültig.

Beispiel lädt ein Demo-Token samt Secret, sodass Sie eine gelungene Prüfung sehen, bevor Sie etwas Eigenes einfügen.
Prüfen nimmt das Secret, einen öffentlichen PEM-Schlüssel, ein einzelnes JWK oder ein ganzes JWKS. Fügen Sie das Dokument von der Adresse /.well-known/jwks.json des Ausstellers ein, und der Schlüssel, den die kid des Tokens nennt, wird automatisch gewählt – die Seite stellt dabei weiterhin selbst keine Anfrage. Wenn Sie außerdem Erwarteter Aussteller und Erwartete Zielgruppe ausfüllen, prüft die Seite eine gültige Signatur so wie ein Server: ein anderes iss oder ein aud ohne Ihren Wert färbt das Ergebnis rot.
Token bauen signiert ein eigenes Token mit jedem der zwölf Algorithmen — die Seite JWT-Generator öffnet genau dort.
Code zeigt die serverseitige Prüfung in acht Sprachen, passend zum Algorithmus im Header Ihres Tokens.
Zwei weitere Seiten öffnen dieses Werkzeug auf eine einzige Frage hin: ist es abgelaufen und warum wird es abgelehnt.

Die Standard-Claims und ihre Bedeutung

Claim	Bedeutung	Typische Fehlerquelle
`iss`	Aussteller des Tokens	Passt nicht, wenn ein Staging-Token an die Produktion geht
`sub`	Subjekt, meist die Nutzer- oder Service-ID	Leer bei Tokens für einen Client statt für eine Person
`aud`	Zielgruppe, also die vorgesehene API	Die häufigste Ursache für ein 401 trotz gültigem Token
`exp`	Ablaufzeit als Unix-Zeitstempel	Liegt in der Vergangenheit oder die Serveruhr weicht ab
`nbf`	Nicht gültig vor diesem Zeitpunkt	Token wurde ein paar Sekunden zu früh benutzt
`iat`	Ausstellungszeitpunkt	Grundlage für maximale Gültigkeitsdauer und Sperrfenster
`jti`	Eindeutige Token-ID	Wird gebraucht, um ein einzelnes Token zu sperren

Dekodieren ist nicht Verifizieren

An diesem Punkt entstehen die meisten Missverständnisse. Ein Token zu lesen zeigt Ihnen, was es behauptet - nicht, ob die Behauptung echt ist. Verifizieren heißt, die Signatur mit dem Secret oder dem öffentlichen Schlüssel des Ausstellers neu zu berechnen und zu vergleichen, dazu Ablauf und Zielgruppe zu prüfen. Jeder Decoder zeigt den Payload eines gefälschten Tokens genauso bereitwillig wie den eines echten. Treffen Sie deshalb nie eine Autorisierungsentscheidung allein auf Basis dekodierter Inhalte, sondern verifizieren Sie serverseitig mit einer gepflegten Bibliothek.

Fehlersuche bei einem Token, das nicht funktioniert

401 trotz gültigem Token: aud mit der Erwartung der API und iss mit der konfigurierten Aussteller-URL vergleichen. Beides unter Erwarteter Aussteller und Erwartete Zielgruppe eintragen und auf Prüfen klicken: Das Ergebnis nennt den Wert, den das Token tatsächlich enthält.
Sofort abgelaufen: exp mit dem Unix-Timestamp-Konverter umrechnen und mit der Serveruhr vergleichen, nicht mit Ihrem Notebook.
Ungültiges Segment: Das Token wurde abgeschnitten, unterwegs URL-kodiert, oder beim Kopieren ist ein Zeilenumbruch hineingeraten.
Signaturprüfung schlägt fehl: Der Schlüssel wurde rotiert, es wurde die falsche Key-ID verwendet, oder das Token stammt aus einer anderen Umgebung.
alg ist none: ablehnen. Dieser Wert kennzeichnet ein unsigniertes Token und ist ein klassischer Angriff auf nachlässige Validierung.

Sicherheitsgewohnheiten, die sich lohnen

Niemals personenbezogene Daten, interne IDs oder Vertrauliches in den Payload schreiben - er ist bewusst lesbar.
Access Tokens kurzlebig halten und für längere Sitzungen ein Refresh Token verwenden.
Tokens ausschließlich über HTTPS übertragen und wo möglich secure, HttpOnly gesetzte Cookies dem Browser-Storage vorziehen.
Signaturschlüssel planmäßig rotieren und über einen JWKS-Endpunkt veröffentlichen, damit Clients folgen können.
Jedes Token, das Sie in ein Online-Werkzeug eingefügt haben, als potenziell offengelegt betrachten - genau deshalb verlässt es hier die Seite nicht.

Funktioniert offline im Browser

Der Decoder ist clientseitiges JavaScript. Nach dem Laden der Seite können Sie Tokens ganz ohne Netzverbindung dekodieren, und Produktivzugangsdaten verlassen Ihren Rechner nie.

Einen JWT im Code oder in der Kommandozeile dekodieren

Wo	Wie
JavaScript (npm)	`import { jwtDecode } from 'jwt-decode'; jwtDecode(token)` - nur die Payload, keine Prüfung
Python (PyJWT)	`jwt.decode(token, options={'verify_signature': False})` zum Lesen, oder den Schlüssel übergeben, um zu prüfen
Bash	`echo $TOKEN \| cut -d. -f2 \| tr '_-' '/+' \| base64 -d 2>/dev/null` - Base64URL lässt das Padding weg, eine kurze Payload braucht daher eventuell ein angehängtes `==`
Browser-Konsole	`JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')))`

Jede dieser Varianten liest den Token, ohne die Signatur zu prüfen - zum Debuggen in Ordnung, für Autorisierungsentscheidungen falsch, siehe den Abschnitt oben.

Passende Werkzeuge

Tokens sitzen zwischen mehreren Formaten. Die rohen Segmente liest der Base64 Decoder, den Payload formatiert der JSON Formatter, exp und iat werden im Timestamp-Konverter zu Datumsangaben, und ein aus einer URL gezogenes Token entschärft der URL Decoder.

Passende Anleitungen

Base64 vs. Base64URL: Was sich ändert und wann Sie welche Variante nutzen Base64URL ist Standard-Base64 mit zwei ausgetauschten Zeichen, - für + und _ für /, und meist ohne das =-Padding. JWT vs. Session-Cookies: Wie sie sich unterscheiden und wann Sie was einsetzen Ein Session-Cookie ist ein Schlüssel zu einem Zustand, den der Server speichert; ein JWT trägt signierten Zustand zum Server. Aus diesem einen Unterschied ergeben sich alle Abwägungen.