Was steckt in einem JWT? Header, Payload und Signatur (2026)

Ein JSON Web Token (JWT) sieht aus wie eine lange Zufallszeichenkette, ist aber nur drei Datenstuecke, die mit Punkten zusammengeklebt sind. Das erste sagt, wie der Token gebaut wurde. Das zweite sind die Claims - fuer wen er ist, wann er ablaeuft, und was der Aussteller sonst reingepackt hat. Das dritte ist eine Signatur, die ein vertrauenswuerdiger Server pruefen kann. Dieser Guide geht jeden Teil durch, die Claims des Alltags, und den Unterschied zwischen Lesen und Vertrauen. Wenn Sie einen echten Token ansehen wollen, fuegen Sie ihn in den JWT-Decoder ein - er laeuft im Browser und laedt den Wert nie hoch.

Drei Teile, verbunden mit Punkten

RFC 7519 definiert ein kompaktes JWT als drei Base64URL-Segmente, getrennt durch einen Punkt. Kein Extra-Wrapper, kein JSON aussenherum, und meist keine Padding-Gleichheitszeichen. Splitten Sie auf ., bekommen Sie immer drei Strings - auch wenn der letzte leer ist (die unsichere Form alg none).

• Header: Metadaten zum Token, fast immer JSON mit alg und typ.
• Payload: die Claims. Das liest eine API wirklich.
• Signatur: eine kryptografische Marke ueber Header und Payload. Dieser Artikel und das Tool behandeln sie als opake Bytes.

Jeder, der JSON schreiben kann, kann einen Header und einen Payload bauen und Base64URL-codieren. Deshalb sind die ersten zwei Teile oeffentlich. Wer ein JWT abfaengt, kann diese Claims lesen. Vertrauliche Daten gehoeren nicht in ein JWT, ausser Sie verschluesseln es zusaetzlich (JWE) - das ist ein anderes Format.

Der Header

Der Header sagt Verifizierern, wie sie den Token behandeln sollen. Es ist ein kleines JSON-Objekt. Nach dem Base64URL-Decodieren des ersten Segments sehen Sie typischerweise:

• alg - der Signaturalgorithmus (oder none). Haeufig: HS256 (HMAC mit Shared Secret), RS256 oder ES256 (asymmetrische Schluessel).
• typ - meist JWT. Manche Aussteller lassen es weg.
• kid - optionale Key-Id, damit ein Server den richtigen Public Key aus einem JWKS waehlt.
• cty - Content-Type, selten, wenn der Payload ein verschachteltes JWT ist.

Das gefaehrliche Header-Feld ist alg. Ein Decoder zeigt, was der Token behauptet. Ein naiver Verifizierer, der alg none akzeptiert oder einen Angreifer von RS256 auf HS256 wechseln und mit dem Public Key wie mit einem HMAC-Secret signieren laesst, akzeptiert gefaelschte Tokens. Das ist ein Server-Bug, kein Problem, das ein Browser-Decoder loest. Lesen Sie alg als Hinweis, nie als Beweis.

Der Payload (Claims)

Der Payload ist ein weiteres JSON-Objekt. JWT-Specs teilen Claims in registrierte Namen (ein kleines gemeinsames Vokabular) und private oder oeffentliche Custom-Namen, die Ihre App definiert. Zeitstempel sind NumericDate-Werte: Sekunden seit 1970-01-01 UTC, nicht Millisekunden.

Registrierte Claims, die Sie oft sehen

• iss - Issuer. Wer den Token ausgestellt hat (eine URL oder ein Auth-Server-Name).
• sub - Subject. Der User oder Service, um den es geht.
• aud - Audience. Die API oder App, die ihn akzeptieren soll. String oder Array.
• exp - Expiration. Token nach dieser Unix-Zeit ablehnen.
• nbf - not before. Token vor dieser Unix-Zeit ablehnen.
• iat - issued at. Wann der Aussteller ihn erzeugt hat.
• jti - JWT-Id. Eine eindeutige Id zum Widerrufen oder Deduplizieren.

Eigene Claims

Alles andere ist Anwendungsdaten: name, email, role, scope, tenant oder ein Permissions-Array. Das ist bequem fuer APIs und trivial zu faelschen, wenn Sie nur decodieren. Ein Claim role: admin in einem Token, den Sie in einen Decoder eingefuegt haben, bedeutet: der Aussteller (oder ein Angreifer) hat diesen String geschrieben. Es ist keine Rechtevergabe, bis ein Backend die Signatur prueft und iss, aud und exp checkt.

Die Signatur

Das dritte Segment ist kein JSON. Bei HS256 ist es ein HMAC-SHA256 ueber den ASCII-String header.payload mit einem Shared Secret. Bei RS256 oder ES256 ist es eine asymmetrische Signatur ueber dieselbe Eingabe. Der Decoder zeigt den rohen Base64URL-Text zum Vergleich; er rechnet die Marke nie nach und prueft sie nie. Verifizieren braucht das Secret oder den Public Key des Ausstellers, und das muss auf einer Maschine passieren, der Sie vertrauen.

Base64URL, nicht gewoehnliches Base64

JWT-Header und -Payload nutzen Base64URL (RFC 4648): dieselbe 6-Bit-Codierung wie Base64, aber + wird zu -, / wird zu _, und das = Padding fehlt oft. So bleiben Tokens in Query-Strings und Headern sicher. Wenn Sie ein JWT-Segment in ein generisches Base64-Tool einfuegen, stellen Sie zuerst die URL-Zeichen wieder her, sonst kommt kein JSON. Der Base64-Encoder / -Decoder ist fuer gewoehnliches Base64; das JWT-Tool wendet das URL-Alphabet schon an.

Durchgerechnetes Beispiel

Der klassische Demo-Token aus der JWT-Doku decodiert zu einem winzigen Header und Payload. Nach dem Split an Punkten und Base64URL-Decode der ersten zwei Teile erhalten Sie:

• Header-JSON: {"alg":"HS256","typ":"JWT"}
• Payload-JSON: {"sub":"1234567890","name":"John Doe","iat":1516239022}
• iat 1516239022 ist 2018-01-18 01:30:22 UTC - der Token waere Jahre ueber jedes echte exp hinaus, falls eines gesetzt war.
• Das dritte Segment ist die HMAC-Signatur. Sie anzusehen sagt nicht, ob das Secret stimmte.

Ein Bearer-Prefix gehoert nicht zum JWT. Authorization: Bearer eyJ... ist eine HTTP-Header-Konvention. Entfernen Sie Bearer und das Leerzeichen, dann decodieren Sie die drei Segmente. Der ToolsMinify-Decoder macht das fuer Sie.

Was Sie lesen koennen vs was ein Server pruefen muss

Nutzen Sie einen Decoder beim Debuggen. Nutzen Sie einen Verifizierer beim Autorisieren.

1. Sie koennen alg, typ und kid lesen, um zu sehen, welchen Key der Aussteller meinte.
2. Sie koennen sub, email oder role lesen, um eine fehlschlagende Request zu verstehen.
3. Sie koennen exp und iat mit einer Uhr vergleichen, um zu sehen, ob der Token alt ist.
4. Ein Server muss die Signatur mit dem richtigen Key und Algorithmus pruefen.
5. Ein Server muss Tokens mit falschem iss oder aud ablehnen, und Tokens die noch nicht gelten oder schon abgelaufen sind.
6. Ein Server muss jeden Claim als untrusted behandeln, bis diese Checks durchlaufen.

Haeufige Fehler

• Claims aus einem Decoder vertrauen. Jeder kann header.payload zusammenbauen und eine Muell-Signatur lassen.
• alg none akzeptieren oder den Token den Verify-Algorithmus waehlen lassen.
• Passwoerter, Session-Secrets oder personenbezogene Daten in den Payload packen. Den Payload liest jeder, der den Token hat.
• Produktions-Tokens auf einer beliebigen Website einfuegen. Lieber einen clientseitigen Decoder, damit der Token die Maschine nicht verlaesst.
• Dieses Format mit verschluesselten JWTs (JWE) verwechseln. Ein kompaktes JWE hat fuenf Segmente, nicht drei.

Haeufige Fragen

Ist ein JWT verschluesselt?

Ein standardmaessig signiertes JWT (JWS) ist nicht verschluesselt. Header und Payload sind nur codiert. Wer den Token hat, liest die Claims. Verschluesselte Tokens nutzen JWE und sehen anders aus. Wenn Sie einen Token in einen Decoder einfuegen und JSON sehen, war er nicht vertraulich.

Warum verifiziert der Decoder die Signatur nicht?

Verifizieren braucht ein Secret oder den Public Key des Private-Key-Inhabers. Die in eine oeffentliche Seite zu legen waere unsicher, und ein gruenes "gueltig"-Badge auf einer untrusted Site wuerde Leute den falschen Check lehren. Lokal decodieren; auf Ihrer API verifizieren.

Was bedeutet alg none?

Es bedeutet, dass der Aussteller (oder ein Angreifer) den Token als ungesichert markiert hat. Das dritte Segment ist leer. Ein Decoder kann Header und Payload trotzdem zeigen. Eine Produktions-API sollte alg none ablehnen, ausser Sie haben einen sehr expliziten, lokalen Grund, unsignierte Tokens zu akzeptieren.

Sind exp und iat in Millisekunden?

Nein. JWT-NumericDate-Werte sind Sekunden seit der Unix-Epoch. Sieht ein Claim wie 1.7e12 aus, schauen Sie wahrscheinlich versehentlich auf JavaScript Date.now() in Millisekunden.

Kann ich einen Token nach einem Payload-Edit neu bauen?

Sie koennen JSON wieder nach Base64URL encodieren und drei Segmente joinen, aber die alte Signatur passt nicht mehr. Ohne das Secret oder den Private Key des Ausstellers ist der neue Token gefaelscht. Das ist erwartet. Decoder sind zum Lesen, nicht zum Ausstellen von Produktions-Tokens.

Wo inspiziere ich einen Token sicher?

Nutzen Sie eine Seite, die im Browser decodiert und den String nicht hochlaedt. Der JWT-Decoder auf ToolsMinify macht das. Fuer die Klick-Anleitung siehe JWT-Decoder verwenden.

Token im Browser inspizieren

Fuegen Sie ein JWT ein, um Header, Payload und Signatur als lesbare Abschnitte zu sehen. Nichts wird hochgeladen:

• JWT-Decoder - Token splitten, Header- und Payload-JSON pretty-printen, jeden Teil kopieren.
• JWT-Decoder verwenden - Schritt-fuer-Schritt-Guide zum selben Tool.
• Base64-Encoder / -Decoder - gewoehnliches Base64, nicht das JWT-URL-Alphabet.
• Hash-Generator - SHA-256-Checksums im Browser. Keine JWT-Signatur.
• Alle Entwickler-Tools - der volle Kategorie-Index.