JWT Encoder

Skapa och signera JSON Web Tokens med HS256, HS384, HS512

Rubrik

Körs lokalt · Säkert att klistra in hemligheter

Nyttolast

Körs lokalt · Säkert att klistra in hemligheter

Hemlig nyckel

Körs lokalt · Säkert att klistra in hemligheter

Kodad JWT

Output will appear here…

Din hemliga nyckel lämnar aldrig din webbläsare. All signering sker på klientsidan.

Prova också:JWT Decoder

Vad är JWT-kodning?

JWT-kodning är processen för att skapa en JSON Web Token — en kompakt, URL-säker sträng som bär en uppsättning anspråk signerade med en kryptografisk nyckel. Resultatet är en tredelig token (header.payload.signature) definierad av RFC 7519 som servrar kan verifiera utan att upprätthålla sessionstillståndet.

Header deklarerar signeringsalgoritmen (t.ex. HS256) och tokentypen. Payload innehåller claims — nyckel-värde-par som subjektet (sub), utgångstid (exp) och anpassad data som din applikation behöver. Båda delarna serialiseras som JSON och base64url-kodas sedan. Signaturen beräknas över den kodade headern och payloaden med hjälp av en hemlig nyckel, vilket binder alla tre segment samman.

Till skillnad från sessionscookies är JWT självinnehållande: verifieraren behöver inte fråga en databas eller anropa en extern tjänst. Detta gör JWT-baserad autentisering populär i REST API:er, mikrotjänster och single-page-applikationer där tillståndslös auktorisering minskar latens och förenklar horisontell skalning.

Varför använda en JWT-kodare?

Att generera JWT manuellt kräver base64url-kodning, JSON-serialisering och HMAC-beräkning. Det här verktyget hanterar alla tre stegen omedelbart så att du kan fokusera på att få claims rätt.

Omedelbar tokengenerering
Redigera header, payload och hemlig nyckel — det signerade JWT uppdateras i realtid. Inget byggsteg, ingen biblioteksinstallation, ingen standardkod.
🔒
Flera HMAC-algoritmer
Växla mellan HS256, HS384 och HS512 med ett klick. Header uppdateras automatiskt och signaturen beräknas om direkt.
🛡️
Integritetsfokuserad bearbetning
All signering sker i din webbläsare med Web Crypto API. Din hemliga nyckel och payload-data lämnar aldrig din enhet — ingen server, inga loggar, ingen risk.
📋
Claim-hjälpare med ett klick
Lägg till iat, exp+1h eller exp+24h-tidsstämplar med en enda knapp. Du behöver inte beräkna Unix-tidsstämplar manuellt eller slå upp aktuell epochtid.

Användningsfall för JWT-kodare

Testning av frontend-autentisering
Generera tokens med specifika claims och utgångstider för att testa inloggningsflöden, token-uppdateringslogik och skyddade rutter utan att köra en backend-autentiseringsserver.
Backend API-utveckling
Skapa testtoken med anpassade sub-, aud- och scope-claims för att testa auktoriseringsmellanvara, rollbaserad åtkomstkontroll och behörighetskontroller under lokal utveckling.
DevOps och CI/CD-pipelines
Generera kortlivade tjänsttoken för driftsättningsskript, integrationstester eller tjänst-till-tjänst-kommunikation där ett fullständigt OAuth-flöde skulle innebära onödig komplexitet.
QA och manuell testning
Bygg tokens med edge-case-claims — utgångna tokens, saknade fält, fel audience — för att verifiera att ditt API returnerar korrekta HTTP 401- eller 403-svar.
Säkerhetsgranskning
Skapa tokens signerade med olika algoritmer och nyckellängder för att validera att din verifieringslogik korrekt avvisar svaga eller felmatchade signaturer.
Lärande och prototypframtagning
Studenter och utvecklare som är nya på JWT kan experimentera med header-fält, claim-strukturer och signeringsalgoritmer för att förstå hur varje del av ett token fungerar.

HS256 vs HS384 vs HS512: Jämförelse av HMAC-algoritmer

Alla tre algoritmer använder HMAC (Hash-based Message Authentication Code) med en delad hemlighet. Skillnaden är den underliggande hashfunktionen, vilket påverkar signaturlängd och säkerhetsmarginal. För de flesta applikationer ger HS256 tillräcklig säkerhet. Välj HS384 eller HS512 när efterlevnadskrav (t.ex. FIPS-140) kräver en starkare hash eller när dina tokens bär högt värderade auktoriseringsbeslut.

AlgoritmHashSignaturHastighetTypisk användning
HS256SHA-25632 BFastestGeneral purpose, default for most libraries
HS384SHA-38448 BFastHigher security margin, FIPS-140 compliant
HS512SHA-51264 BFastMaximum HMAC security, large payloads

Referens för standard-JWT-claims

RFC 7519 definierar sju registrerade claims. Ingen är obligatorisk, men att använda dem korrekt förbättrar interoperabilitet och säkerhet. Claim exp är särskilt viktig — tokens utan utgångsdatum är giltiga på obestämd tid om hemligheten inte roteras.

ClaimNamnBeskrivningExempel
issIssuerWho issued the token"auth.example.com"
subSubjectWho the token represents"user-123"
audAudienceIntended recipient service"api.example.com"
expExpirationUnix timestamp — token invalid after this time1717203600
nbfNot BeforeUnix timestamp — token invalid before this time1717200000
iatIssued AtUnix timestamp when the token was created1717200000
jtiJWT IDUnique token identifier for revocation tracking"a1b2c3d4"

JWT-kodning i kod

Dessa exempel visar hur man skapar och signerar JWT programmatiskt. Varje kodavsnitt producerar ett giltigt HS256-signerat token. För produktionssystem, ange alltid exp-claimet och använd en kryptografiskt slumpmässig hemlighet på minst 256 bitar.

JavaScript (Web Crypto API)
async function signJWT(payload, secret, alg = 'HS256') {
  const header = { alg, typ: 'JWT' }
  const enc = new TextEncoder()

  // Base64url encode header and payload
  const b64url = (obj) =>
    btoa(JSON.stringify(obj)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  const h = b64url(header)
  const p = b64url(payload)

  // Sign with HMAC-SHA256
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(`${h}.${p}`))
  const s = btoa(String.fromCharCode(...new Uint8Array(sig)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  return `${h}.${p}.${s}`
}

// Usage
const token = await signJWT(
  { sub: 'user-123', name: 'Alice', iat: Math.floor(Date.now() / 1000) },
  'your-256-bit-secret'
)
// → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."
Python (PyJWT)
import jwt
import time

payload = {
    "sub": "user-123",
    "name": "Alice",
    "iat": int(time.time()),
    "exp": int(time.time()) + 3600,  # expires in 1 hour
}

# Sign with HS256 (default)
token = jwt.encode(payload, "your-256-bit-secret", algorithm="HS256")
# → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."

# Verify and decode
decoded = jwt.decode(token, "your-256-bit-secret", algorithms=["HS256"])
# → {"sub": "user-123", "name": "Alice", "iat": 1717200000, "exp": 1717203600}
Node.js (jsonwebtoken)
const jwt = require('jsonwebtoken')

const payload = {
  sub: 'user-123',
  name: 'Alice',
  role: 'admin',
}

// Sign — iat is added automatically
const token = jwt.sign(payload, 'your-256-bit-secret', {
  algorithm: 'HS256',
  expiresIn: '1h',    // sets exp claim
  issuer: 'auth.example.com',  // sets iss claim
})

// Verify
const decoded = jwt.verify(token, 'your-256-bit-secret')
// → { sub: 'user-123', name: 'Alice', role: 'admin', iat: ..., exp: ... }
Go (golang-jwt)
package main

import (
    "fmt"
    "time"
    "github.com/golang-jwt/jwt/v5"
)

func main() {
    claims := jwt.MapClaims{
        "sub":  "user-123",
        "name": "Alice",
        "iat":  time.Now().Unix(),
        "exp":  time.Now().Add(time.Hour).Unix(),
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    signed, _ := token.SignedString([]byte("your-256-bit-secret"))
    fmt.Println(signed)
    // → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOi...
}

Vanliga frågor

Vad är skillnaden mellan JWT-kodning och JWT-avkodning?
JWT-kodning skapar ett signerat token från en header, payload och hemlig nyckel. JWT-avkodning vänder processen — den läser tillbaka den base64url-kodade headern och payloaden till JSON. Avkodning kräver inte hemligheten; kodning gör det alltid eftersom signaturen måste beräknas.
Hur lång bör min JWT-hemliga nyckel vara?
För HS256, använd en hemlighet på minst 256 bitar (32 bytes). För HS384, använd minst 384 bitar (48 bytes). För HS512, använd minst 512 bitar (64 bytes). Kortare hemligheter accepteras tekniskt av de flesta bibliotek men minskar den faktiska säkerheten hos HMAC-signaturen. Generera hemligheter med en kryptografiskt säker slumpgenerator, inte en av människor vald lösenfras.
Är det säkert att använda det här verktyget med riktiga hemliga nycklar?
Det här verktyget bearbetar allt i din webbläsare med Web Crypto API — ingen data skickas till någon server. Undvik ändå att klistra in produktionshemligheter i något webbverktyg som en allmän säkerhetspraxis. För produktionsnyckelhantering, använd miljövariabler eller en hemlighetshanterare som HashiCorp Vault eller AWS Secrets Manager.
Ska jag använda HS256 eller RS256 för min applikation?
Använd HS256 när samma tjänst både skapar och verifierar tokens — det är snabbare och enklare. Använd RS256 (asymmetriskt) när tredjepartstjänster behöver verifiera dina tokens utan möjlighet att skapa dem. RS256 är vanligt i OAuth 2.0-leverantörer, OpenID Connect och arkitekturer för SaaS med flera klienter.
Varför upphör mitt JWT att gälla omedelbart efter skapandet?
Claim exp använder Unix-tidsstämplar i sekunder, inte millisekunder. Om du sätter exp till Date.now() (som returnerar millisekunder) verkar token upphöra att gälla tusentals år in i framtiden — eller om du av misstag använder ett millisekundersvärde där sekunder förväntas kan bibliotek tolka det som redan utgånget. Använd alltid Math.floor(Date.now() / 1000) i JavaScript eller int(time.time()) i Python.
Kan jag lägga känslig data i JWT-payloaden?
Det är möjligt men rekommenderas inte. JWT-payloaden är base64url-kodad, inte krypterad — vem som helst med token kan läsa claims. Lagra inte lösenord, kreditkortsnummer eller personuppgifter i payloaden. Om du måste inkludera känslig information, använd JWE (JSON Web Encryption) enligt RFC 7516, som krypterar hela payloaden.
Vad händer om jag ändrar payloaden efter signering?
Signaturen blir ogiltig. HMAC-signaturen beräknas över de exakta bytena i den kodade headern och payloaden. Varje ändring — även att lägga till ett mellanslag eller ändra ett enda tecken — ger en helt annan signatur. En korrekt implementerad verifierare avvisar token med ett signaturmatchningsfel.