Kodierung
JWT Encoder/Decoder
Kodierung und Dekodierung von JWT-Tokens — Header, Payload, HMAC-Signatur und Standardfelder.
Signierte Beispiele (alle außer none) erfordern HTTPS — die Seite ist derzeit ohne HTTPS geöffnet.
Für RS/PS/ES wird der Schlüssel automatisch und temporär erzeugt — nur zu Demonstrationszwecken, kann nicht wiederverwendet werden.
Signierte Beispiele (alle außer none) erfordern HTTPS — die Seite ist derzeit ohne HTTPS geöffnet.
Claims
A JWT (JSON Web Token) is a compact format for transmitting signed data, made of three dot-separated parts: a header, a payload, and a signature. This tool decodes any JWT and shows all three parts, and can also build a new token signed with HMAC.
Decoding does not verify the signature — reading a token's contents needs no secret key. Verifying the signature only matters when you need to trust the token as genuine.
How to use it
- Decode: paste a JWT and the tool splits it into header, payload, and signature, highlighting standard claims like exp, iat, and sub.
- Encode: fill in the header and payload, provide a secret, and get a signed HMAC token (HS256/HS384/HS512) back.
- Check expiry: the exp claim is shown as a normal date, so you can immediately tell if a token has expired.
Common uses
- Debugging authentication issues by inspecting exactly what a request's token contains.
- Checking which claims (roles, permissions, expiry) your backend issues.
- Generating a test token for local development without running an auth server.
Things to keep in mind
A JWT is not encrypted, only Base64URL-encoded — anyone can read the payload. Never put passwords or other secrets in it.
The signature protects against tampering, not against being read. For confidentiality you need extra encryption (JWE) or an HTTPS transport.
Artikel zu diesem Tool: JWT: Aufbau eines Tokens und was „Dekodieren" eines JWT bedeutet
Häufig gestellte Fragen
Beweist das Dekodieren eines JWT, dass es authentisch ist?
Nein. Beim reinen Dekodieren werden Header und Payload nur lesbar gemacht, ohne die Signatur zu prüfen. Ein Token ist erst dann als echt bestätigt, wenn die Signatur mit dem richtigen Secret oder öffentlichen Schlüssel verifiziert wurde.
Verlässt mein Secret oder Token diesen Browser?
Nein, das gesamte Kodieren, Dekodieren und Signieren läuft lokal im Browser über die Web Crypto API. Es wird nichts an einen Server gesendet.
Warum ist beim Signieren manchmal HTTPS erforderlich?
Signierte Beispiele (alle Algorithmen außer none) nutzen die Web Crypto API, die aus Sicherheitsgründen nur in einem sicheren Kontext (HTTPS oder localhost) verfügbar ist.
Was ist die Angriffstechnik mit der Algorithmus-Verwechslung auf "none"?
Vertraut ein Backend naiv dem Feld alg aus dem Header des Tokens, kann ein Angreifer es auf none setzen, die Signatur entfernen – und ein Token mit beliebigen Daten besteht die Prüfung. Zuverlässige Bibliotheken verlangen bei der Verifizierung die explizite Angabe des erwarteten Algorithmus.
Warum sollte man JWT nicht in localStorage für sensible Sitzungen speichern?
localStorage ist für jeden JavaScript-Code auf der Seite zugänglich und damit anfällig für XSS – ein schädliches Skript kann den Token stehlen. Für Session-Tokens sind httpOnly-Cookies sicherer, da sie für JavaScript nicht zugänglich sind.