logo
GeekFormat

JWT Decoder

Encoded Token172 charsBijgewerkt 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Onderwerp1234567890
name· NameJohn Doe
admin· Admintrue
iat· Uitgegeven op151623902218-01-2018, 09:30:22
Header details2 items
algHS256HMAC (symmetrisch)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Gratis online JWT tool voor het decoderen, verifiëren en genereren van JWT-tokens. Bekijk Header, Payload en handtekening details voor API authenticatie debugging.

Gerelateerde aanbevelingen

Toepassingsgevallen

  • JWT online decoderen: snel een token splitsen tijdens OAuth 2.0 / OIDC login debugging om Header algoritme en Payload Claims te inspecteren
  • JWT handtekeningen verifiëren: gebruik een Secret / publieke sleutel om token handtekeningen in real-time te valideren en te bepalen of een 401 'slechte handtekening', 'verlopen' of 'algoritme mismatch' is
  • Test JWT's genereren tijdens integratie: geef een JWT uit in de browser met een test sleutelpaar, zonder dat de backend tijdelijk code moet wijzigen om een token te maken
  • PEM ↔ JWK conversie: de OIDC IdP gaf je JWK maar de server heeft PEM nodig (of andersom) — converteer ter plekke in plaats van een OpenSSL script te schrijven
  • Diagnose 401 Unauthorized: stap voor stap verloop, alg-vs-gateway match, sleutel match en PEM formattering controleren
  • RS256 vs PS256 vergelijken: veel OIDC providers gebruiken standaard RS256 terwijl AWS SigV4 de voorkeur geeft aan PS256 — wissel van algoritme met hetzelfde RSA sleutelpaar en vergelijk resultaten
  • JWT internals leren: verander de alg, bewerk de Payload, wissel de sleutel in de browser en zie de handtekening in real-time breken — veel sneller dan de RFC lezen

Functies

  • Decoderen + Verifiëren + Genereren op één plek: plak een token om Header/Payload/Signature te splitsen, wissel van algoritme en sleutel om de handtekening te verifiëren, bewerk Claims en onderteken opnieuw om een nieuw token te maken — dekt de volledige JWT troubleshooting-keten
  • Alle 13 algoritmen ondersteund: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — dekt OAuth 2.0, OIDC, JWS, API-gateways en enterprise SSO
  • PEM en JWK formaten: RSA, ECDSA en Ed25519 sleutels accepteren PEM-strings (met -----BEGIN PUBLIC KEY----- headers) en JWK JSON (kid/kty/n/e velden) — plaats direct een OIDC /.well-known/jwks.json uitvoer
  • Meerdere HMAC secret invoervormen: raw UTF-8 string, hex bytes, of Base64/Base64URL-gecodeerde secret — wissel met één klik, zodat 'lijkt hetzelfde maar handtekening faalt' nooit gebeurt
  • Automatische sleutelpaar generatie: RSA-2048, RSA-4096, P-256, P-384 en Ed25519 sleutelparen gegenereerd in-browser, gepresenteerd in zowel PEM als JWK formaten voor direct testgebruik
  • Semantische Claims markering: exp / iat / nbf automatisch omgezet naar leesbare tijd met verlopen / nog-niet-geldig / uitgegeven status gemarkeerd; alg / typ / kid in Header apart gelabeld
  • 100% client-side, zero upload: elke parse, verify en sign draait via de browser's native Web Crypto API — tokens, sleutels en payload verlaten nooit de browser, volgens het beveiligingsprincipe van 'plak nooit productietokens in willekeurige online tools'
  • Eén-klik kopie: Header, Payload, Signature en het nieuw gegenereerde token zijn elk onafhankelijk kopieerbaar voor documentatie, tickets en curl commando's

Hoe te gebruiken

  1. Plak of typ het token: plaats de JWT string in het invoerveld; de tool splitst automatisch Header, Payload en Signature en toont elk als JSON
  2. Selecteer het algoritme: wissel tussen HS256 / RS256 / ES256 / PS256 / EdDSA; de tool leidt af uit Header.alg en markeert elke mismatch
  3. Importeer een sleutel: plak een HMAC secret, een PEM string, of een JWK JSON; voor asymmetrische algoritmen, klik op 'Genereer sleutelpaar' om direct een testsleutel te krijgen
  4. Verifieer of onderteken opnieuw: in Decode modus verifieer met een publieke sleutel en zie '✅ handtekening geldig / ❌ handtekening ongeldig'; in Encode modus bewerk Claims en onderteken met een private sleutel om een nieuw token te maken

Veelgestelde vragen

Waaruit bestaan de drie delen van een JWT?

Een JWT string heeft de vorm `Header.Payload.Signature`, elk segment is Base64URL-gecodeerd. Header declareert het algoritme (zoals HS256, RS256) en het token type (typ: JWT); Payload draagt gebruikers Claims (beweringen), veelvoorkomende velden zijn sub (gebruikers ID), iat (uitgiftetijd), exp (vervaltijd), nbf (niet-voor), aud (publiek), iss (uitgever); Signature is het resultaat van het ondertekenen van de eerste twee segmenten met een sleutel, het doel is 'tamper-evidence' niet 'anti-lekken'.

Kan ik de Payload aanpassen na het decoderen?

Je kunt bekijken en bewerken, maar **niet vals spelen**. Zodra je de Header of Payload wijzigt, wordt de originele Signature ongeldig en zal de server verificatie weigeren. Om het gewijzigde token opnieuw bruikbaar te maken, moet je het **opnieuw ondertekenen** met hetzelfde algoritme en dezelfde sleutel — dit is precies waarom deze tool 'decoderen + bewerken + genereren' in één biedt: decodeer om te bekijken, wijzig en genereer direct een nieuw token voor testen, zodat je niet elke keer de backend tijdelijk code hoeft te laten wijzigen om uit te geven.

Wat is het verschil tussen HS256, RS256, ES256, PS256 en EdDSA?

HS256 gebruikt HMAC met een gedeeld Secret (symmetrisch), snel maar Secret-beheer is cruciaal. RS256 gebruikt RSA private/publieke sleutels (asymmetrisch), de uitgever ondertekent met private, de verifier gebruikt public. ES256 gebruikt ECDSA met elliptische curves (P-256), kortere handtekening. PS256 gebruikt RSA-PSS, veiliger dan RS256. EdDSA (meestal Ed25519) is snel en deterministisch, aanbevolen voor OAuth 2.1.

Waarom krijg ik steeds 'Invalid Signature'?

Meestal komt dit doordat de sleutel, Secret formaat, algoritme of Base64URL codering niet exact overeenkomt. Een extra spatie, verkeerde PEM regelafbreking of Base64 vs Base64URL verwarring is al genoeg. Controleer byte-voor-byte overeenkomst en bevestig dat Header.alg overeenkomt met het geselecteerde algoritme.

Kan dezelfde RSA-sleutel RS256 en PS256 cross-verifiëren?

Nee. RS256 gebruikt RSASSA-PKCS1-v1_5, PS256 gebruikt RSA-PSS. Zelfs met dezelfde RSA sleutel kunnen ze niet cross-verifiëren. De ondertekenaar en verifier moeten hetzelfde algoritme gebruiken.

Wat is een alg:none aanval?

Een aanvaller wijzigt de Header naar `{"alg":"none"}` (geen handtekening) of vervangt RS256 door HS256 (door de publieke sleutel te gebruiken alsof het een HMAC secret is). De server moet een algoritme whitelist afdwingen en nooit het token laten bepalen welk algoritme te gebruiken.

Hoe converteer ik tussen PEM en JWK?

PEM is de klassieke OpenSSL notatie met BEGIN/END regels. JWK is JSON en gebruikelijk in OAuth/OIDC. OIDC providers publiceren publieke sleutels vaak via `/.well-known/jwks.json`. Deze tool kan PEM en JWK formaten direct verwerken.

Kan ik JWT handtekeningen direct in de browser verifiëren?

Ja. De browser's native Web Crypto API (`window.crypto.subtle`) ondersteunt HMAC, RSA, ECDSA, RSA-PSS en Ed25519 signing en verificatie, zonder third-party libraries. Deze tool gebruikt `crypto.subtle.importKey` en `crypto.subtle.verify` op de front-end voor elke verificatie, daarom uploadt het nooit je tokens of sleutels. Let op: Web Crypto is alleen beschikbaar in secure contexts: **HTTPS** of `localhost`.

Wordt mijn token naar een server gestuurd?

Nee. Alle parsing, verificatie en signing in deze tool draait in de browser via de native Web Crypto API. Het token, Header, Payload, Signature, Secret / private sleutel, en eventuele gegenereerde sleutelparen worden nooit naar een server gestuurd. Open de browser DevTools Network tab en je zult geen outbound request zien die token inhoud draagt. De pagina kan offline worden gebruikt zodra hij is geladen.

Is JWT een veilige plek voor gevoelige gebruikersinformatie?

**Nee.** JWT Payload is standaard plaintext — iedereen met het token kan het Base64URL-decoderen en de inhoud lezen. Er is geen encryptie. **Zet nooit** wachtwoorden, nationale ID nummers, creditcard nummers, API keys, access tokens of refresh tokens in plaintext in een JWT. Als je encryptie nodig hebt, gebruik JWE (RFC 7516) in plaats van JWS. JWTs zijn geschikt voor niet-gevoelige Claims (gebruikers ID, rol, vervaltijd, tenant ID); gevoelige data moet server-side worden opgezocht met `sub`.

Wat is JWT Decoderen, Verifiëren en Genereren?

JWT (JSON Web Token) is een open standaard gedefinieerd door IETF in RFC 7519 (RFC 7515 beschrijft de JWS signing vorm, RFC 7516 beschrijft JWE encryptie, RFC 7517 definieert JWK sleutels) voor het veilig overdragen van 'beweerde' gebruikersinformatie tussen HTTP verzoeken, OIDC flows en microservice aanroepen. Een standaard JWT string bestaat uit drie Base64URL-gecodeerde segmenten: Header (algoritme en type), Payload (Claims, de gebruikersdata) en Signature (een op sleutel gebaseerde handtekening over de eerste twee). De drie segmenten zijn verbonden met een letterlijke punt `.`, bijv. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT is geen encryptie.** Dit is het meest voorkomende misverstand. De Payload is standaard plaintext — iedereen kan het Base64URL-decoderen en de inhoud lezen. JWT biedt **tamper-evidence**, niet vertrouwelijkheid: de server hertekent Header.Payload met de gedeelde sleutel en vergelijkt met de Signature van het token. Als ze overeenkomen, is het token niet gewijzigd tijdens transport. Dit is de 'treinkaartje met anti-vervalsstempel' metafoor: de inspecteur vraagt of het ticket echt is, niet of de QR-code onleesbaar is.

JWT verdeelt verantwoordelijkheden netjes over 13 algoritmen. **HMAC familie** (HS256/HS384/HS512) gebruikt een symmetrische sleutel voor zowel signing als verifying, snel en eenvoudig, geschikt voor een enkele service of een vertrouwd cluster; de secret moet minstens de digest lengte zijn (bijv. ≥ 32 bytes voor HS256). **RSA familie** (RS256/RS384/RS512) gebruikt RSASSA-PKCS1-v1_5, het meest voorkomende asymmetrische schema — ondertekenaars houden de private sleutel, verifiers houden de publieke sleutel. **RSA-PSS familie** (PS256/PS384/PS512) gebruikt de nieuwere RSA-PSS padding met sterkere beveiligingsgaranties, de voorkeur van AWS SigV4 en moderne OIDC identity providers. **ECDSA familie** (ES256/ES384/ES512) gebruikt elliptische curves (respectievelijk P-256/P-384/P-521) met kortere handtekeningen en betere prestaties. **EdDSA** (voornamelijk Ed25519) is extreem snel en deterministisch (zelfde bericht +zelfde sleutel = dezelfde handtekening elke keer) en is het aanbevolen algoritme in OAuth 2.1 en nieuwe protocollen.

Beveiliging is waar JWT struikelt in productie. De OWASP JWT Cheat Sheet noemt minstens vier harde regels: (1) zet nooit wachtwoorden, nationale ID's, kaartnummers of API keys als plaintext in de Payload; (2) de server moet **nooit het alg veld vertrouwen** dat in de Token Header staat — het moet verifiëren met een hard-coded algoritme, anders omzeilt een aanvaller die de header herschrijft naar `alg: none` alles (dit is de oorzaak van historische CVE's zoals CVE-2015-9235); (3) HMAC secrets moeten random zijn en minstens 32 bytes, nooit korte strings; (4) verificatie is meer dan alleen handtekening checks — je moet ook `exp` (vervaltijd), `nbf` (not-before), `iss` (issuer) en `aud` (audience) valideren. Deze tool markeert elk van deze Claims in de UI zodat je in één oogopslag kunt zien of een failure een handtekening probleem, een timing probleem, of een Claims probleem is.

JWT is geen vervanging voor sessies. Sessies slaan gebruikersstatus op de server op (Redis of een database); JWT stopt de status in het token. Microservice architecturen, stateless APIs, mobiele clients en CORS-heavy setups profiteren van JWT; traditionele enterprise systemen en flows die directe intrekking vereisen (bijv. 'kick deze gebruiker er nu uit') zijn nog steeds beter bediend met sessies. Deze tool dekt zowel pure JWT debugging als de Token-parsing / signature-verifying / Payload-editing stappen van een sessie-naar-JWT migratie.

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalSymmetrisch sleutelalgoritme. Dezelfde Secret ondertekent en verifieert, eenvoudig en snel, geschikt voor service clusters binnen een vertrouwde grens. Secret moet minstens 32 random bytes zijn.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIHet meest voorkomende asymmetrische algoritme. Onderteken met de private sleutel, verifieer met de publieke sleutel. Standaard voor de meeste OIDC IdPs, API gateways en enterprise SSO.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS is de bijgewerkte, veiligere vervanger voor RS256. AWS SigV4, AWS Cognito en moderne OIDC providers geven er de voorkeur aan. saltLength moet expliciet worden opgegeven.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIElliptische curve handtekeningen. Korte handtekeningen (ES256 is slechts 64 bytes), snelle prestaties, kleinere JWTs. Apple Sign in with Apple gebruikt standaard ES256.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APINext-generation high-performance handtekening algoritme. Deterministische handtekeningen (zelfde bericht +zelfde sleutel produceert altijd hetzelfde resultaat), geen nonce-hergebruik risico, aanbevolen door OAuth 2.1.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL):  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature:            kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

Deze JWT werkbank draait 100% in je browser, ondersteund door de browser's native Web Crypto API. Het token dat je plakt, de Header, de Payload, de Signature, de HMAC Secret, eventuele RSA/ECDSA private sleutels, eventuele gegenereerde sleutelparen, en elke handtekening/verify berekening blijven op je apparaat — ze reizen nooit naar een server, worden nooit gelogd, nooit geanalyseerd, en nooit gecached. De pagina kan offline worden gebruikt zodra hij is geladen. Best practice: plak nooit langlevende productietokens of productie private sleutels in een online tool, inclusief deze. Deze tool is geschikt voor debugging, integratie testing, leren en het maken van test tokens — productie secrets en private sleutels moeten worden behandeld in een gecontroleerde, lokale omgeving.

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

Het token en de verificatiesleutel komen niet overeen. De gebruikelijke oorzaken: (1) de sleutel van de server en de sleutel die je in de tool hebt geplakt zijn verschillend (meest voorkomend); (2) de sleutel bevat onzichtbare tekens (trailing spatie, newline, zero-width char); (3) Base64 en Base64URL zijn door elkaar gehaald; (4) het verkeerde algoritme is geselecteerd (Header zegt HS256, server verifieert als RS256, of andersom). Controleer eerst of de sleutel byte-voor-byte overeenkomt: let op PEM trailing newlines, HMAC secret trailing spaties, en JWK `k` waarden die mogelijk verkeerd URL-gedecodeerd zijn. Bevestig dat het algoritme in de tool overeenkomt met de Header.alg van het token. Gebruik de decode-plus-verify van deze tool om de exacte fout te reproduceren en te bevestigen dat het gebeurt tussen 'decode gelukt' en 'verify mislukt'.

HTTP 401 Unauthorized: Token Expired of iat in de toekomst

Handtekening verificatie geslaagd, maar `exp` is in het verleden (Token Expired), `nbf` is nog in de toekomst (Not Before), of `iat` is later dan de huidige tijd van de server (vaak door klok skew). Een ander veelvoorkomend geval is een verkeerde `aud` (audience): het token is uitgegeven voor App A maar gevalideerd door App B. Gebruik het gemarkeerde Claims gebied in deze tool om exp / nbf / iat status in één oogopslag te zien. Rood exp = verlopen, geef opnieuw uit. Rood nbf = nog niet geldig, controleer of iat een toekomstige tijd is. Rood aud = verkeerde audience, controleer of de server de juiste audience geconfigureerd heeft.

PEM of JWK import fout

PEM heeft extra lege regels of mist header/footer markers (`-----BEGIN PUBLIC KEY-----`); JWK mist vereiste velden (`kty` / `n` / `e` / `kid`); JWK `k` waarde mist Base64URL padding (moet `=`-gepadded of strikt `=`-gestript zijn); een RSA private sleutel wordt als public sleutel geïmporteerd; een Ed25519 private sleutel (32-byte seed) wordt als 64 bytes geleverd. Herexporteer een standaard PKIX PEM met `openssl rsa -in key.pem -pubout -outform PEM` of `openssl ec -in key.pem -pubout`; gebruik voor JWK de raw uitvoer van de OIDC Discovery `/.well-known/jwks.json` endpoint in plaats van zelf de encoding te doen. Deze tool detecteert automatisch PEM headers, ontbrekende padding en ontbrekende JWK velden en geeft een hint.

RS256 vs PS256 cross-language handtekening failures

RS256 gebruikt RSASSA-PKCS1-v1_5, PS256 gebruikt RSA-PSS. De twee **kunnen niet cross-verifiëren** — een token ondertekend met RS256 door een gegeven RSA sleutel zal altijd PS256 verificatie falen, en de handtekening kan in lengte een paar bytes verschillen. Zorg dat de ondertekenaar en de verifier hetzelfde algoritme gebruiken. AWS SigV4 gebruikt PS256, de meeste OIDC IdPs gebruiken RS256. RSA-PSS heeft ook een `saltLength` parameter — OpenSSL standaard 32, jose standaard 32, Go's `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` is de juiste equivalent. Zet dit vast voordat je cross-language integratie testing doet.

alg: none aanval en HS256-key-substitution aanval

De server kiest een verificatie algoritme op basis van de alg die in de Header van het token staat. Een aanvaller herschrijft de header naar `alg: none` (geen handtekening) of herschrijft een RS256 token naar HS256 (door de publieke sleutel te gebruiken alsof het een gedeelde HMAC secret is) en omzeilt verificatie. Historische CVE's zoals CVE-2015-9235 (jsonwebtoken) en CVE-2022-23529 (meerdere Node libraries) herleiden naar dit patroon. De server moet een algoritme whitelist afdwingen — bijvoorbeeld `algorithms: ['RS256']` — en mag het token nooit laten bepalen welk algoritme te gebruiken. De UI van deze tool toont zowel Header.alg als het algoritme dat je daadwerkelijk hebt geselecteerd, en markeert mismatches: dat is zelf een live demo van 'de client moet Header.alg niet vertrouwen'.