JWT Online kodieren
Erstelle mit HMAC-SHA256 signierte JWT-Tokens für Tests und Entwicklung. Kostenlos, in deinem Browser, ohne Daten-Upload.
Warum diesen Encoder verwenden
JWT für die Entwicklung, ohne Komplikationen
Vollständige Privatsphäre
Das Token wird mit der Web Crypto API direkt in deinem Browser erzeugt. Weder Payload noch Geheimschlüssel verlassen jemals dein Gerät.
Echte kryptografische Signierung
Wir verwenden HMAC-SHA256 über die Web Crypto API – denselben Algorithmus, den Produktionsserver verwenden. Das Token ist gültig und verifizierbar.
Kompatibel mit jeder JWT-Bibliothek
Das erzeugte Token entspricht RFC 7519. Funktioniert mit jsonwebtoken (Node.js), PyJWT (Python), java-jwt und jeder konformen Implementierung.
Sofort, ohne Netzwerkabhängigkeit
Keine Server-Aufrufe. Die Erzeugung erfolgt in Millisekunden unabhängig von deiner Verbindung.
So funktioniert es
Drei Schritte, kein Aufwand
Payload definieren
Schreibe den JSON-Payload mit den benötigten Claims: sub, exp, iat oder beliebige benutzerdefinierte Felder.
Geheimschlüssel eingeben
Gib den Geheimschlüssel für die HMAC-SHA256-Signierung ein. Verwende nur Testschlüssel – niemals Produktions-Secrets in Browser-Tools.
Erzeugtes Token kopieren
Das signierte JWT-Token wird sofort in deinem Browser erzeugt. Kopiere es für die Verwendung in deinen API-Tests.
FAQ
Noch Fragen?
HMAC-SHA256 ist ein Signierungsalgorithmus, der deinen Geheimschlüssel mit dem Base64URL-kodierten Header und Payload kombiniert, um eine kryptografische Signatur zu erzeugen. Das stellt sicher, dass das Token nicht manipuliert wurde.
NEIN – gib niemals Produktions-Geheimschlüssel in Browser-Tools ein. Dieses Tool dient zur Erzeugung von Test-Tokens in Entwicklungsumgebungen. Schlüssel bleiben auf deinem Gerät, aber das Risiko einer Exposition besteht jedes Mal, wenn du echte Secrets in ein Web-Textfeld eingibst.
HS256 (HMAC-SHA256) ist der Standard- und häufigste Algorithmus für symmetrische JWTs. Er ist der Standard für die meisten Implementierungen, die keine asymmetrische Kryptografie (RS256/ES256) erfordern.
Ja. Das erzeugte JWT-Token kann mit unserem JWT-Decode-Tool dekodiert werden, um Header und Payload zu überprüfen. Beachte, dass der Payload nur Base64URL-kodiert, nicht verschlüsselt ist – jeder kann seinen Inhalt lesen.
Ja. Füge beliebige JSON-Schlüssel-Wert-Paare zum Payload hinzu. Standard-Claims wie sub (Subjekt), iss (Aussteller) und aud (Zielgruppe) werden genauso behandelt wie benutzerdefinierte – sie sind einfach Konventionen des JWT-Standards.
exp (Ablauf) und iat (Ausstellungszeitpunkt) sind Unix-Zeitstempel in Sekunden. Für ein Token, das in 1 Stunde abläuft: iat ist der aktuelle Zeitstempel und exp ist iat + 3600. Den aktuellen Zeitstempel erhältst du mit Date.now()/1000 in der Browser-Konsole.
JWT-Erstellungs-Workflow, HMAC-SHA256-Signierprozess, Web Crypto API für Kryptografie, JWT-Tests in der API-Entwicklung
JSON Web Token (JWT) ist ein offener Standard (RFC 7519), der ein kompaktes, eigenständiges Format zur sicheren Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert. Ein JWT besteht aus drei durch Punkte getrennten Teilen: dem Header (Token-Typ und Signierungsalgorithmus), dem Payload (die Claims oder Behauptungen) und der Signatur (kryptografische Signatur). Jeder Teil ist Base64URL-kodiert, was das Token sicher für die Verwendung in URLs und HTTP-Headern macht.
Der HS256-Algorithmus (HMAC mit SHA-256) ist der häufigste für symmetrische JWTs: Sowohl der Aussteller als auch der Empfänger teilen denselben Geheimschlüssel. Die Signatur wird berechnet als HMAC-SHA256(Base64URL(Header) + '.' + Base64URL(Payload), Secret). Die Web Crypto API des Browsers implementiert HMAC-SHA256 nativ, was die Erzeugung kryptografisch gültiger Tokens ermöglicht, ohne Daten an einen Server zu senden.
In der REST-API-Entwicklung wird JWT hauptsächlich für zustandslose Authentifizierung verwendet: Der Server erzeugt beim Login ein Token, der Client speichert es (localStorage oder httpOnly-Cookie) und sendet es mit jedem Request im Authorization-Header als Bearer-Token. Der Server muss nur die Signatur mit seinem Geheimschlüssel verifizieren, ohne Datenbankabfragen. Die wichtigsten Standard-Claims sind sub (Benutzerkennung), exp (Ablaufzeit in Unix-Sekunden), iat (Ausstellungszeitpunkt) und iss (Token-Aussteller).