JWT-Generator

JSON Web Tokens mit HS256/384/512 erstellen und signieren

100 % kostenlos. Läuft vollständig in deinem Browser: deine Dateien und Daten verlassen dein Gerät nie, und es wird nichts auf einen Server hochgeladen.

title Header
data_object Payload (Claims)
Custom Claims (JSON)
key Signaturgeheimnis
Erzeugtes Token
Signed JWT will appear here

Jump to the next useful tool without leaving your flow.

See more

Über dieses Tool

Erstellt und signiert JSON Web Tokens (JWTs) mit HS256/384/512-Algorithmen - nützlich zum Testen einer API, die ein JWT erwartet, zum Lernen der JWT-Struktur oder zum Erzeugen eines Tokens für eine Dev-/Testumgebung ohne vollen Auth-Server.

So verwendest du dieses Tool

  1. Payload-Claims definierenSetze Subject, Issuer, Expiry, Rollen und Custom Claims nach Bedarf.
  2. Signaturalgorithmus wählenWähle HS256/384/512 passend zu den Verifikationserwartungen der Ziel-API.
  3. Token mit Secret signierenErzeuge den JWT-String und prüfe dekodierten Header/Payload.
  4. Testen und prüfenNutze den Token in Dev-API-Requests und bestätige das Auth-Verhalten.

Was in einen JWT gehört

Nimm die Standard-Claims auf, die ein Server braucht: sub (für wen der Token ist), iat (ausgestellt am), exp (Ablauf) und oft iss (Aussteller) und aud (Zielgruppe). Halte den Payload klein und pack niemals Passwörter oder Secrets hinein – jeder, der den Token hat, kann ihn lesen.

Halte Access Tokens kurzlebig – 5 bis 60 Minuten sind üblich – und nutze Refresh Tokens für längere Sitzungen.

Warum es nutzen

  • Beschleunigt API-Auth-Tests ohne vollen Identity-Stack.
  • Hilft, JWT-Struktur und Claim-Verhalten sichtbar zu machen.
  • Nützlich für QA, Integrationstests und lokales Debuggen.
  • Unterstützt gängige HMAC-JWT-Signaturvarianten.

Häufige Anwendungen

  • Geschützte API-Endpoints in der Entwicklung testen.
  • Rollenbasierte Tokens für Frontend-QA simulieren.
  • Claim-Parsing und Expiry-Handling debuggen.
  • Auth-Test-Fixtures für automatisierte Integrationssuiten bauen.

Tipps für bessere Ergebnisse

  • Nutze kurze Expirations für Tests sicherheitssensibler Flows.
  • Nutze nie Produktions-Signing-Secrets in Browser-Tools.
  • Nimm nur nötige Claims, damit Tokens minimal bleiben.
  • Validiere Algorithmuserwartungen auf dem Server, um Missbrauch zu verhindern.

Fehler, die du vermeiden solltest

  • Erzeugte Dev-Tokens direkt in Produktionssystemen nutzen.
  • Den Expiry-Claim vergessen und langlebige unsichere Tokens erzeugen.
  • JWTs öffentlich in Logs oder Screenshots teilen.
  • Annehmen, unsignierte/schwach signierte Tokens seien für Auth sicher.

Häufig gestellte Fragen

Dieses Tool eignet sich am besten für Tests, Lernen und Entwicklung - für echte Produktions-Auth sollten Tokens serverseitig mit den tatsächlichen Secret Keys und der Infrastruktur deiner Anwendung erzeugt und signiert werden, nicht mit einem Drittanbieter-Browser-Tool.

Es ist derselbe HMAC-basierte Signaturansatz mit unterschiedlichen Hash-Funktionen (SHA-256, SHA-384, SHA-512) - höhere Zahlen bedeuten eine längere, rechenintensivere Signatur, HS256 ist aber der meistgenutzte Default in den meisten Systemen.

Das Signieren läuft in deinem Browser, aber als allgemeine Vorsicht: Nutze hier einen Test-/Wegwerf-Secret statt eines echten Produktionssecrets, besonders weil JWTs oft für echte Authentifizierung genutzt werden.

Üblich sind sub (der Nutzer), iat (Ausstellungszeit), exp (Ablauf) und oft iss (Aussteller) und aud (Zielgruppe). Halte Tokens klein und leg keine Geheimnisse hinein - die Nutzlast ist nur Base64-kodiert, nicht verschlüsselt.

Kurzlebige Access-Tokens von 5-60 Minuten sind üblich, ergänzt durch ein Refresh-Token für längere Sitzungen. Ein langlebiges JWT lässt sich bei einem Leak nur schwer widerrufen.

Mindestens 256 Bit (32 Zufallsbytes) für HS256, länger für HS384 und HS512. Ein kurzes oder erratbares Secret erlaubt Angreifern, gültige Tokens zu fälschen.

Related guides