01
Automatisches Lesen bewusst nutzen
Die Dekodierung wartet nach Änderungen 350 ms. Schalte sie aus, um Dekodieren oder Ctrl/Cmd+Enter zu verwenden. Signaturprüfung und Testgenerierung starten dadurch niemals automatisch.
Öffentliche Schlüssel prüfen
JWT-Decodermit getrennten Signatur- und Claim-Prüfungen
Erst lesen, dann Algorithmus, öffentlichen Schlüssel und erwartete Claims selbst festlegen.
JWT-Decoder
JWT-Token
Token und Schlüssel bleiben im Arbeitsspeicher dieser Seite. Keine Speicherung und keine Anfragen nach entfernten Schlüsseln.
Dekodiertes JSON und Bericht
Ungeprüft: Dekodieren bestätigt keine Gültigkeit.
Signatur- und Claim-Einstellungen
Wähle den erwarteten Algorithmus selbst. Eine passende Signatur bestätigt weder Ausstelleridentität noch Berechtigungen, Widerrufsstatus oder die gesamte Gültigkeit.
Eigener öffentlicher Schlüssel
Ein öffentlicher JWK oder SPKI PEM PUBLIC KEY. RS256 benötigt RSA mit 2048–8192 Bit, ES256 benötigt P-256. Keine privaten Schlüssel oder entfernten JWKS.
exp, nbf und iat werden unabhängig von der Signatur geprüft. Ein zukünftiges iat wird hier beanstandet. Fehlende Zeiten bleiben fehlend; leere Aussteller- oder Zielgruppenfelder bleiben ungeprüft. UTC zeigt Millisekunden, der ursprüngliche Bruchteil bleibt im Bericht.
Grenzen: Token 100.000 Zeichen, Schlüssel 20.000, Test-Claims 50.000. Nur striktes base64url, UTF-8 und JSON-Objekte. Doppelte Schlüssel und Zahlen mit Wertänderung werden abgelehnt.
Testtoken-Generator
Füge ein kompaktes JWT ein.
Der JWT-Decoder hilft bei abgelehnten API-Anfragen: Lies Header und Claims, vergleiche Aussteller sowie Zielgruppe und untersuche die Zeitangaben. So erkennst du, ob tatsächlich das erwartete Token gesendet wurde. Die Signatur bleibt zunächst ungeprüft.
JWT dekodieren bedeutet, die base64url-Daten lesbar zu machen. Um eine JWT Signatur prüfen zu können, brauchst du zusätzlich den passenden Schlüssel; die JWT Ablaufzeit ist eine eigenständige Bedingung. Der Bericht vermischt diese Ergebnisse nicht zu einer pauschalen Gültig-Aussage.
Warum dieser JWT-Decoder getrennte Ergebnisse zeigt
Lesbarer Inhalt ist noch kein Vertrauensbeweis
Der JWT-Decoder lässt eine passende Signatur neben einem fehlgeschlagenen Zeitcheck stehen. Ein abgelaufenes Token kann unverändert sein, ein plausibles JSON dagegen gefälscht. Damit lässt sich gezielter untersuchen, warum die Anwendung ablehnt.
Tests in einem eigenen Entwurf
Der separate Generator erstellt ein temporäres lokales Schlüsselpaar und zeigt Token sowie öffentlichen Schlüssel zunächst als Vorschau. Erst Anwenden ersetzt die Eingaben. Einmal Rückgängig stellt vorherige Eingabe und Ergebnis wieder her.
Erwartungen vor dem Prüfen festlegen
02
Vertrauensgrundlage selbst angeben
Wähle RS256 oder ES256 und füge einen öffentlichen JWK oder SPKI PUBLIC KEY PEM ein. Trage bei Bedarf den erwarteten Aussteller und die Zielgruppe ein. Header-Verweise wählen keinen Schlüssel aus.
03
Mit einer festen Zeit reproduzieren
Ein leeres Zeitfeld nutzt bei jedem Lauf die aktuelle Zeit. Unix-Sekunden erlauben eine reproduzierbare Referenz. Die Aktion für die aktuelle Zeit zeigt erst eine Ersetzungsvorschau; nach Änderungen bleibt alter Export gesperrt.
Ablehnungsgründe gezielt unterscheiden
Einen JSON Web Token analysieren
Die Ansicht zeigt beide JSON-Objekte und Signaturinformationen. Der deklarierte Algorithmus bleibt vom erwarteten Algorithmus getrennt; kid und URLs sind keine Vertrauensanker.
Öffentliche Schlüssel vergleichen
RS256 unterstützt RSA mit 2048–8192 Bit, ES256 die Kurve P-256. Eine nicht passende Signatur wird von ungültigen Schlüsseln, nicht unterstützten Algorithmen und Formatfehlern unterschieden.
Zeitbedingungen reproduzieren
exp, nbf und iat werden mit Referenzzeit und 0–86400 Sekunden Toleranz geprüft. Zukünftiges iat gilt nach dieser Debugger-Richtlinie als fehlgeschlagen. Fehlende Zeiten bleiben als fehlend markiert.
Aussteller und Zielgruppe abgleichen
iss verlangt eine exakte Zeichenfolge. aud kann eine Zeichenfolge oder ein Array sein, das die erwartete Zielgruppe enthält. Leere Erwartungen bleiben ungeprüft; eine Signatur erteilt keine Berechtigungen.
Formatgrenzen und Vertrauensmodell
- Nur drei kompakte Segmente
- Gib das reine Token ohne Bearer-Präfix, umgebende Leerzeichen oder Padding ein. Fünfteilige JWE werden nicht entschlüsselt. none lässt sich mit leerer Signatur lesen, wird aber niemals bestätigt.
- Strikte Zeichen- und Zahlenprüfung
- Header und Claims müssen UTF-8-JSON-Objekte sein. Doppelte Namen, einzelne Surrogate und nicht kanonisches base64url werden abgelehnt. Darstellbare Bruchteile sind erlaubt; stille Wertänderungen beim Konvertieren nicht.
- Nur öffentliche Schlüssel importieren
- Erlaubt sind ein öffentlicher JWK oder vollständiger SPKI PUBLIC KEY PEM. Private und symmetrische Schlüssel werden abgelehnt. Widersprüchliche Angaben in alg, use oder key_ops verhindern die Prüfung ebenfalls.
- Keine entfernten Schlüssel oder Erweiterungen
- jku, x5u, kid, jwk und x5c sind nur nicht vertrauenswürdige Metadaten. Sie lösen keinen Abruf und keine Schlüsselauswahl aus. Signaturen mit crit, b64 oder zip werden nicht geprüft.
- Größen und Zeitdarstellung
- Grenzen: 100.000 Tokenzeichen, 20.000 Schlüsselzeichen, 50.000 Test-Claim-Zeichen. Auch erzeugte Token müssen unter der Tokengrenze bleiben. Zeiten außerhalb des Date-Bereichs sind ungültig; UTC zeigt Millisekunden, der Bericht behält den Bruchteil.
- Testen ist keine Authentifizierung
- Der Generator ist anfangs deaktiviert und erzeugt erst auf ausdrücklichen Aufruf temporäre Schlüssel. Anwenden startet keine Signaturprüfung. Berechtigungen, Widerruf und Anwendungsregeln bleiben Aufgabe des empfangenden Systems.
Fragen zum JWT-Decoder
Worin unterscheiden sich Dekodieren und Verifizieren?
Dekodieren stellt lesbares JSON ohne Schlüssel her. Verifizieren vergleicht die Signatur mit dem ausdrücklich gewählten Algorithmus und öffentlichen Schlüssel. Eine erfolgreiche Signaturprüfung ersetzt weder Zeit- noch Berechtigungsprüfungen.
Ist die JWT-Payload verschlüsselt?
Bei einem gewöhnlichen signierten JWT ist die Payload lediglich base64url-kodiert. Jeder Besitzer kann sie lesen. Eine Signatur schützt Integrität, aber keine Vertraulichkeit; Passwörter gehören nicht in die Payload.
Was bedeuten die Felder exp, nbf und iat?
exp begrenzt das Ende, nbf den frühesten Beginn und iat beschreibt die Ausstellung, jeweils in Unix-Sekunden. Dieses Werkzeug beanstandet auch zukünftiges iat. Die Prüfungen verwenden Referenzzeit und eingestellte Toleranz.
Was passiert bei einem fehlerhaften Token?
Ungültiges base64url, UTF-8, JSON oder doppelte Namen führen zu einem Fehler. Der alte Bericht darf dann nicht exportiert werden. Fehlende Zeit-Claims werden dagegen als fehlend angezeigt, ohne erfundene Erfolgsmeldung.
Werden Token und Schlüssel gespeichert?
Die Eingaben bleiben nur im Speicher der aktuellen Seite. Es gibt keine Entwürfe im Browserspeicher und keinen Abruf entfernter Schlüssel. Ein Bericht wird erst durch bewusstes Kopieren oder Herunterladen ausgegeben.
Ein unerwartetes Prüfergebnis?
Mit der Untersuchung fortfahren
Verwende den JWT-Decoder mit erwartetem Algorithmus, bekanntem öffentlichen Schlüssel und bewusster Zeitreferenz; exportiere nur den Bericht zum aktuellen Stand.