Kostenlose Entwickler-Tools

JWT-Decoder & Debugger.

Ein Token dekodieren, Header und Payload mit Live-Neusignierung bearbeiten und Signaturen verifizieren — ohne dass das Token je deinen Browser verlässt.

In der EU entwickelt und gehostet
JWT-Debugger
Dekodieren · bearbeiten · prüfen
Läuft komplett in deinem Browser
Header Payload Signatur

Signatur

Füge ein Token ein, um es zu untersuchen und seine Signatur zu verifizieren.

Dekodieren, Signieren und Verifizieren laufen komplett in deinem Browser — nichts wird übertragen oder gespeichert. Trotzdem: Behandle Produktions-JWTs wie Passwörter.

Was ist ein JWT?

Ein JSON Web Token (RFC 7519) ist eine kompakte, in sich geschlossene Möglichkeit, Claims zwischen Parteien zu übertragen — meist der Nachweis, wer ein Benutzer ist und was er darf. Weil das Token signiert ist, kann eine API seinem Inhalt ohne Datenbankabfrage vertrauen, was JWTs zum Rückgrat von zustandsloser Authentifizierung, OAuth 2.0 und OpenID Connect macht.

Drei Teile, durch einen Punkt getrennt

  • Header — Metadaten: der Signaturalgorithmus (alg) und der Token-Typ.
  • Payload — die Claims: registrierte wie exp und sub, plus alles, was der Aussteller hinzufügt.
  • Signatur — ein MAC oder eine digitale Signatur über die ersten beiden Teile, die Integrität und Herkunft belegt.

Jeder Teil ist Base64URL-kodiert — kodiert, nicht verschlüsselt. Jeder kann den Inhalt eines JWT lesen; nur die Signatur ist geschützt.

Dekodieren ist nicht Verifizieren

Der häufigste JWT-Fehler: eine dekodierte Payload als vertrauenswürdig zu behandeln. Dekodieren braucht keinen Schlüssel — ein Angreifer kann jede beliebige Payload erstellen. Vertrauen entsteht nur durch das Verifizieren der Signatur gegen dein Secret (HS256) oder den öffentlichen Schlüssel des Ausstellers (RS256/ES256) und durch die Prüfung von exp, iss und aud. Serverseitige Bibliotheken erledigen das für dich — konfiguriere eine explizite Allowlist erlaubter Algorithmen.

Halte deine Tokens sicher

  • Lege niemals Secrets oder personenbezogene Daten in die Payload — sie ist für jeden lesbar.
  • Halte die Lebensdauer von Access-Tokens kurz und erneuere sie mit Refresh-Tokens.
  • Übertrage Tokens nur über HTTPS und speichere sie außerhalb der Reichweite eingeschleuster Skripte.
  • Lehne alg: none ab und verifiziere gegen eine Allowlist erlaubter Algorithmen.

Häufige Fragen

Ist es sicher, ein JWT in einen Online-Decoder einzufügen?
Dieser Debugger läuft komplett in deinem Browser — dein Token wird nie übertragen, gespeichert oder protokolliert, was du im Netzwerk-Tab deiner Entwicklertools überprüfen kannst. Trotzdem: Behandle Produktions-Tokens wie Passwörter — ein JWT gewährt oft Zugriff auf ein Konto oder eine API. Nutze nach Möglichkeit Test-Tokens, hier wie in jedem anderen Tool.
Was ist der Unterschied zwischen dem Dekodieren und dem Verifizieren eines JWT?
Dekodieren liest nur das Token: Header und Payload sind Base64URL-kodiert, nicht verschlüsselt, daher kann sie jeder dekodieren. Verifizieren prüft die kryptografische Signatur gegen ein Secret oder einen öffentlichen Schlüssel und belegt, dass das Token von der erwarteten Partei ausgestellt und nicht manipuliert wurde. Vertraue den Claims eines Tokens nie, ohne seine Signatur zu verifizieren.
Kann ich ein Token bearbeiten und eine gültige Signatur erhalten?
Ja — bei HMAC-Algorithmen (HS256/384/512) gibst du das gemeinsame Secret ein, und der Debugger signiert das Token bei jeder Änderung an Header oder Payload automatisch neu. Bei asymmetrischen Algorithmen wie RS256 braucht das Signieren den privaten Schlüssel, den du niemals in eine Website einfügen solltest — deshalb bleibt bei Änderungen die alte Signatur bestehen und wird als ungültig gemeldet.
Kann ich ein JWT dekodieren, ohne den geheimen Schlüssel zu kennen?
Ja — Dekodieren braucht überhaupt keinen Schlüssel, denn Header und Payload sind nur Base64URL-kodiert. Das Secret oder der private Schlüssel wird nur benötigt, um eine gültige Signatur zu erstellen, und das Secret oder der öffentliche Schlüssel, um eine zu verifizieren.
Was sind die Standard-Claims eines JWT?
RFC 7519 definiert sieben registrierte Claims: iss (Issuer), sub (Subject), aud (Audience), exp (Ablaufzeit), nbf (nicht gültig vor), iat (ausgestellt am) und jti (eindeutige Token-ID). Alle sind optional, und Anwendungen fügen ihre eigenen Custom Claims hinzu — Rollen, E-Mail, Scopes.
Warum wird mein Token als abgelaufen markiert?
Der Claim exp enthält einen Unix-Timestamp (in Sekunden); ist dieser Zeitpunkt überschritten, muss das Token abgelehnt werden. Abgelaufene Tokens sind normal — Access-Tokens sind oft nur Minuten gültig. Deine Anwendung sollte ein neues Token beziehen, üblicherweise über ein Refresh-Token, statt das alte zu verlängern.
Was ist der Unterschied zwischen HS256 und RS256?
HS256 ist symmetrisch: Dasselbe Secret signiert und verifiziert, sodass jeder verifizierende Dienst auch Tokens fälschen könnte. RS256 ist asymmetrisch: Ein privater Schlüssel signiert, ein teilbarer öffentlicher Schlüssel verifiziert. Nutze RS256 (oder ES256), sobald Tokens Dienstgrenzen überschreiten; HS256 ist in Ordnung, wenn derselbe Dienst sie ausstellt und konsumiert.
Was bedeutet alg: none und warum ist es gefährlich?
Ein ungesichertes JWT hat gar keine Signatur. Akzeptiert ein Server naiv alg: none, kann ein Angreifer beliebige Tokens fälschen. Bibliotheken sollten mit einer expliziten Allowlist erlaubter Algorithmen konfiguriert werden; dieser Debugger kennzeichnet solche Tokens mit einer Warnung.
Kann dieses Tool verschlüsselte JWTs (JWE) dekodieren?
Nein. JWE-Tokens (fünf Base64URL-Segmente statt drei) sind tatsächlich verschlüsselt, und ihr Lesen erfordert den Entschlüsselungsschlüssel. Dieses Tool verarbeitet die weitaus häufigeren JWS-Tokens — die signierte Variante mit drei Segmenten.

Kostenlose Tools von einem europäischen Software-Unternehmen.

  • Läuft in deinem Browser
  • In der EU gehostet
  • Kein Konto nötig