Skip to content

JWT decoderen — online JWT-decoder

Decodeer JWT-tokens direct in je browser. Inspecteer header, payload, signature, vervaldatum en claims. 100% privé — je token verlaat je apparaat nooit.

Geen tracking Draait in je browser Gratis
JWT Token
Beoordeeld op RFC 7519-conformiteit en privacygaranties — Go Tools Security Team · Apr 22, 2026

Wat is een JWT?

Een JSON Web Token, of JWT (uitgesproken als 'jot'), is een compact, URL-veilig tokenformaat voor het overdragen van claims tussen twee partijen. Het is gedefinieerd in RFC 7519 en is het dominante credentialformaat voor OAuth 2.0-access tokens, OpenID Connect ID-tokens, API-sleutels bij moderne auth-providers (Auth0, Okta, Clerk, Supabase, Firebase) en service-to-service tokens in microservice-architecturen.

"JSON Web Token (JWT) is een compact claims-representatieformaat bedoeld voor omgevingen met beperkte ruimte, zoals HTTP Authorization-headers en URI-queryparameters." — RFC 7519, Sectie 1

Een JWT bestaat uit drie via Base64URL geëncodeerde JSON-objecten gescheiden door punten: header.payload.signature. De header beschrijft hoe het token is ondertekend (de alg-claim — bijvoorbeeld HS256 of RS256 — en de typ-claim, doorgaans 'JWT'). De payload bevat de claims: geregistreerde claims zoals iss, sub, aud, exp, iat, plus welke aangepaste claims de uitgever nodig heeft (role, scope, email, tenant ID). De signature is een cryptografisch bewijs, berekend over de header en payload met de geheime of private sleutel van de uitgever, waarmee de ontvanger manipulatie kan detecteren.

Cruciaal: een JWT is geëncodeerd, niet versleuteld. Iedereen met het token kan de payload lezen — decoderen is slechts Base64URL en JSON-verwerking. De beveiligingsgarantie komt van de signature: een aanvaller kan een JWT lezen, maar kan geen andere JWT produceren die signature-verificatie doorstaat zonder de ondertekeningssleutel. Daarom zijn JWT's veilig om via het netwerk te versturen, maar onveilig om te vullen met geheimen.

Een JWT decoder toont je precies wat een token bevat — algoritme, claims, vervaldatum — zonder de signature aan te raken. Het is de snelste manier om te beantwoorden: 'Is dit token verlopen?', 'Welke role heeft deze gebruiker?', 'Welke uitgever heeft dit token aangemaakt?' of 'Is dit een alg:none-token dat ik moet afwijzen?'. Alle decodering in deze tool vindt lokaal in je browser plaats, zodat het plakken van een live productietoken veilig is.

JWT-gebruik gaat vaak samen met andere developer tools. Je moet misschien een Base64URL-gewikkeld segment decoderen bij het debuggen van een misvormd token, een URL-geëncodeerde Authorization-header decoderen nadat je hem uit een proxy hebt vastgelegd, of de exp-claim handmatig omrekenen naar een leesbare datum. Base64URL is de basis waarop elk JWT is gebouwd — lees meer over hoe Base64-codering werkt in de technische uitleg bij de Base64 decoder/encoder.

// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
  const decode = (seg) => JSON.parse(
    atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
  );
  return { header: decode(h), payload: decode(p), signature: s };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // → { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // → { sub: 'user_123', exp: 1999999999, ... }

// Expiration check
const expired = payload.exp * 1000 < Date.now();

Functies

Direct JWT decoderen

Plak en zie het JWT in realtime decoderen — header, payload en signature direct zichtbaar. Geen knop, geen round-trip naar een server.

Vervaldatumdetectie

Leest automatisch de exp-claim en toont een rode badge wanneer het token verlopen is, met de exacte vervaldatum in je lokale tijdzone.

Algoritme-agnostisch

Decodeert elk JWS-algoritme — HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA en alg:none.

100% lokaal

Decoderen vindt plaats in je browser via native atob en JSON.parse. Je token wordt nooit geüpload — veilig voor productiecredentials.

Claim-bewuste weergave

Markeert de geregistreerde RFC 7519-claims (iat, exp, nbf, iss, aud, sub, jti) zodat je auth-problemen in één oogopslag herkent.

Met één klik kopiëren

Kopieer de header-JSON, payload-JSON of ruwe signature naar je klembord met één klik — ideaal voor bugrapporten en tests.

Voorbeelden

HS256 Token (Geldig)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0
{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}

HMAC-SHA256-ondertekend token met een subject, role en een toekomstige vervaldatum — de meest gebruikte JWT-opzet voor sessie-authenticatie.

RS256 Token (Verlopen)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0yMDI1LTAxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsImlhdCI6MTYwMDAwMDAwMCwiZXhwIjoxNjAwMDAzNjAwLCJzY29wZSI6InJlYWQ6dXNlciB3cml0ZTpwb3N0In0.signature_placeholder
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "iat": 1600000000,
  "exp": 1600003600,
  "scope": "read:user write:post"
}

RSA-ondertekend OAuth-stijl access token — let op de kid (key ID) in de header en de exp-claim die aangeeft dat het token al verlopen is.

OIDC ID Token

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJzdWIiOiIxMTA1MDIyNTExNTU4OTkwNzY2Mzk1IiwiYXpwIjoiY2xpZW50LWlkIiwiYXVkIjoiY2xpZW50LWlkIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OSwibm9uY2UiOiJhYmMxMjMifQ.signature
{
  "alg": "ES256",
  "typ": "JWT"
}

{
  "iss": "https://accounts.google.com",
  "sub": "110502251155899076639",
  "azp": "client-id",
  "aud": "client-id",
  "email": "alice@example.com",
  "email_verified": true,
  "iat": 1715000000,
  "exp": 1999999999,
  "nonce": "abc123"
}

OpenID Connect ID-token met ECDSA-signature, e-mailclaims en een nonce voor replay-beveiliging.

Alg: none Token (Onondertekend)

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZWJ1Zy11c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.
{
  "alg": "none",
  "typ": "JWT"
}

{
  "sub": "debug-user",
  "iat": 1715000000
}

Onondertekend token met alg:none. Dit in productie accepteren is een klassieke JWT-kwetsbaarheid — wijs alg:none altijd server-side af.

Zo gebruik je het

  1. 1

    Plak je JWT om te decoderen

    Plak het volledige JWT — inclusief de drie door punten gescheiden segmenten — in het invoerveld. De decoder draait direct in je browser; je hoeft niet op een knop te klikken.

  2. 2

    Lees de gedecodeerde header, payload en status

    Lees het algoritme en tokentype in de gedecodeerde header, de claims in de payload en de vervaldatum- en uitgiftedatum-chips bovenaan. Een verlopen token wordt rood gemarkeerd.

  3. 3

    Kopieer de gedecodeerde uitvoer

    Gebruik de kopieerknop op elk paneel om de gedecodeerde header-JSON, payload-JSON of ruwe signature te kopiëren. Je token is nergens naartoe gestuurd — decoderen vond lokaal in je browser plaats.

Common Errors

alg:none accepteren

Een onondertekend JWT kan door iedereen worden vervalst. Sta alg:none nooit toe in productie — geef altijd een expliciete algoritmenlijst mee aan je verify-aanroep.

✗ Fout
jwt.verify(token, secret)  // library default may allow 'none'
✓ Correct
jwt.verify(token, secret, { algorithms: ['RS256'] })

Ontbrekende exp-claim

Een JWT zonder exp is voor altijd geldig. Als een token ooit uitlekt, is er geen natuurlijk intrekkingspunt. Stel altijd een vervaldatum in die past bij het tokentype.

✗ Fout
{ "sub": "user_123", "role": "admin" }  // no exp
✓ Correct
{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

Geheimen opslaan in de payload

JWT-payloads zijn niet versleuteld — iedereen met het token kan ze lezen. Stop nooit wachtwoorden, API-sleutels of onafgekorte PII in een JWT-payload.

✗ Fout
{ "sub": "user_123", "password": "hunter2" }
✓ Correct
{ "sub": "user_123", "role": "admin" }  // payload stays minimal

Veelvoorkomende toepassingen

Authorization Bearer-tokens decoderen
Decodeer JWT-tokens uit Authorization: Bearer-headers om de claims, audience en vervaldatum te verifiëren die je backend ontvangt.
OAuth 2.0- en OIDC-tokens decoderen
Decodeer access tokens en ID-tokens die worden geretourneerd door autorisatieservers (Auth0, Okta, Google, Keycloak) tijdens OAuth 2.0- en OpenID Connect-integratie.
Verlopen sessies diagnosticeren
Bevestig in één seconde of een afgewezen token verlopen is, de verkeerde audience gebruikt of een klokafwijkingsprobleem heeft.
Sleutelrotatie controleren
Lees de kid (key ID) in de header om te verifiëren dat je JWKS-rotatie tokens uitgeeft die zijn ondertekend met de verwachte sleutel.
Beveiligingsreviews
Spoor tokens op die zijn ondertekend met alg:none, een ontbrekende exp hebben of PII lekken in de payload tijdens code-review en pentesting.
Microservice-tokens inspecteren
Decodeer service-to-service tokens binnen een mesh om te zien welke scopes en welk subject een downstream aanroep autoriseert.

Technische details

RFC 7519-conform
Verwerkt JWS-tokens conform RFC 7519 (JWT), RFC 7515 (JWS) en RFC 7518 (JWA) — alle geregistreerde algoritmen worden ondersteund voor decodering.
Base64URL-decodering
Gebruikt het URL-veilige Base64-alfabet (- en _ in plaats van + en /) zoals gedefinieerd in RFC 4648, met padding-tolerante verwerking.
Browser-native, nul afhankelijkheden
Gebouwd op de native browserfuncties atob, TextDecoder en JSON.parse — geen externe bibliotheken, geen netwerkoproepen, geen telemetrie.

Best practices

Vertrouw nooit zonder te verifiëren
Een decoder toont claims; hij bewijst ze niet. Verifieer de signature altijd server-side aan de hand van de sleutel van de uitgever voordat je een claim vertrouwt.
Wijs alg:none af in productie
Configureer je JWT-bibliotheek met een expliciete acceptatielijst van algoritmen. Accepteer alg:none nooit en wees alert op alg-mismatches bij sleutelrotatie.
Houd payloads beknopt
Zet identificatoren en kortlevende claims in het JWT; bewaar omvangrijke data achter een ondoorzichtig sessie-ID. Grote tokens kosten bandbreedte bij elk verzoek.

Veelgestelde vragen

Hoe decodeer ik een JWT-token online?
Plak het volledige JWT — alle drie de door punten gescheiden segmenten (header.payload.signature) — in de decoder hierboven. Decoderen gebeurt direct in je browser: de header en payload worden via Base64URL gedecodeerd naar leesbare JSON en de signature wordt als onbewerkte string weergegeven. Een statusrij toont het ondertekeningsalgoritme, de uitgiftedatum en de vervaldatum, zodat je een verlopen token in één oogopslag herkent. Om een JWT handmatig te decoderen, splits je het token op punten, decodeer je de eerste twee segmenten via Base64URL en lees je ze als JSON-object — iedereen met het token kan de claims lezen, want de payload is geëncodeerd, niet versleuteld. Deze decoder is veilig te gebruiken met productietokens omdat er nooit iets je apparaat verlaat: geen netwerkverzoek, geen logging, geen tracking.
Wat is een JWT (JSON Web Token)?
Een JSON Web Token (JWT) is een compacte, URL-veilige credential die claims overdraagt tussen twee partijen. Gedefinieerd in RFC 7519, bestaat het uit drie via Base64URL geëncodeerde secties gescheiden door punten: de header (algoritme en tokentype), de payload (claims — gegevens over de gebruiker en het token zelf) en de signature (cryptografisch bewijs dat het token door een vertrouwde partij is uitgegeven). JWT's zijn de standaardmanier om access tokens in OAuth 2.0 en ID-tokens in OpenID Connect voor te stellen.
Is mijn token veilig bij deze JWT decoder?
Ja. Alle decodering vindt plaats in je browser via native JavaScript (atob en TextDecoder). Je token wordt nooit naar een server gestuurd, nooit gelogd, nooit opgeslagen en nooit voor analyses gebruikt. Er zijn geen cookies en geen tracking. Dit is belangrijk omdat JWT's live access tokens kunnen bevatten — ze in een externe debugger plakken zou gelijkstaan aan het afgeven van een credential. Onze tool is veilig te gebruiken met productietokens.
Hoe werkt een JWT decoder?
Een JWT decoder splitst het token op punten in drie delen, decodeert de header en payload via Base64URL en leest ze als JSON-object. De signature blijft een ondoorzichtige Base64URL-string, omdat verificatie de geheime of publieke sleutel van de uitgever vereist — iets wat een client-side decoder niet veilig kan doen. Decoderen is daardoor direct en onthult de claims, maar je moet de signature server-side verifiëren met de juiste sleutel voordat je de inhoud vertrouwt.
Kan deze tool een JWT-signature verifiëren?
Nee, en dat is bewust zo. Signature-verificatie vereist de geheime sleutel van de uitgever (voor HMAC) of de publieke sleutel (voor RSA/ECDSA/EdDSA), die nooit in een publieke webtool geplakt mogen worden. Verificatie moet plaatsvinden op je server, in je auth-middleware of in een SDK met toegang tot je JWKS-endpoint. Deze decoder is bedoeld voor het inspecteren van wat een token beweert — hij impliceert niet dat het token authentiek of ongewijzigd is.
Wat zijn iat, exp, nbf, iss, aud, sub en jti?
Dit zijn de geregistreerde claims uit RFC 7519. iat (issued at) is de Unix-timestamp van het moment dat het token is aangemaakt. exp (expiration) is het moment waarop het token niet meer geldig is — deze tool zet het om naar een leesbare datum en markeert het token als verlopen wanneer exp in het verleden ligt. nbf (not before) is de vroegste tijd waarop het token gebruikt mag worden. iss (issuer) geeft aan wie het token heeft aangemaakt. aud (audience) noemt de beoogde ontvanger. sub (subject) identificeert de principal — meestal een gebruikers-ID. jti is een uniek token-ID om replay-aanvallen te voorkomen. Applicatiespecifieke claims (role, scope, email, name) staan naast deze geregistreerde claims.
Mijn JWT is verlopen — waarom decodeert de decoder hem toch?
Decoderen is niet hetzelfde als valideren. Een JWT decoder leest de inhoud ongeacht de vervaldatum, zodat je een verlopen of anderszins ongeldig token kunt inspecteren om te begrijpen waarom hij werd afgewezen. De 'Verlopen'-badge in deze tool vergelijkt de exp-claim met je lokale klok en markeert tokens waarvan de exp in het verleden ligt. Een echte authenticatieserver zou het token direct afwijzen — maar een decoder die verlopen tokens weigert te tonen, is waardeloos voor debuggen.
Wat is het verschil tussen JWT, JWS en JWE?
JWT is het algemene concept — een JSON-object geëncodeerd als een compact token. JWS (RFC 7515) is een ondertekend JWT: de payload is leesbaar voor iedereen die hem decodeert, en een signature bewijst dat er niet mee geknoeid is. Dit is verreweg het meest voorkomende JWT dat je tegenkomt. JWE (RFC 7516) is een versleuteld JWT: de payload zelf is versleutelde tekst en kan niet worden gedecodeerd zonder de decryptiesleutel. Deze tool decodeert JWS-tokens. Een JWE-token decodeert alleen de header — de versleutelde payload is niet leesbaar zonder de sleutel.
Waarom is alg:none gevaarlijk?
Een JWT met alg:none heeft geen signature — iedereen kan er één aanmaken en beweren wie dan ook te zijn. Vroege JWT-bibliotheken accepteerden alg:none standaard, wat leidde tot een bekende categorie authenticatieomzeilingen waarbij een aanvaller de signature verwijderde, alg instelde op none en een admin-token vervalsde. Elke volwassen JWT-bibliotheek weigert alg:none nu tenzij expliciet toegestaan, en je mag het nooit accepteren voor geauthenticeerde verzoeken. Deze decoder toont je een alg:none-token toch, want het inspecteren ervan tijdens debuggen is legitiem — maar behandel elk dergelijk token dat je in productie ontvangt als vijandig.
Welke algoritmen ondersteunt deze JWT decoder?
Het decoderen van de header en payload werkt voor elk algoritme, omdat decoderen alleen Base64URL en JSON-verwerking vereist — het is algoritme-agnostisch. De tool leest correct tokens ondertekend met HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA + SHA), PS256, PS384, PS512 (RSA-PSS), ES256, ES384, ES512 (ECDSA), EdDSA (Ed25519/Ed448) en onondertekende tokens (alg:none). Alleen signature-verificatie is algoritme-specifiek, en deze tool voert geen verificatie uit.
Moet ik JWT's opslaan in localStorage of cookies?
Gebruik bij voorkeur HttpOnly, Secure, SameSite=Strict cookies voor sessietokens. Een token in localStorage is leesbaar voor elke JavaScript die op de pagina draait, waardoor één XSS-kwetsbaarheid elke actieve sessie blootstelt. HttpOnly-cookies zijn onzichtbaar voor JavaScript, wat de impact van XSS beperkt tot wat een aanvaller tijdens een actieve sessie kan doen — niet een gestolen token dat hij dagenlang opnieuw kan gebruiken. Als je localStorage toch moet gebruiken (bijvoorbeeld voor cross-domain apps), houd dan de levensduur van access tokens kort (minuten, niet uren) en gebruik een apart refresh token in een HttpOnly-cookie.
Hoe decodeer ik een JWT in Node.js, Python of Go?
Node.js: jsonwebtoken.decode(token) voor alleen lezen, jsonwebtoken.verify(token, key) voor verificatie. Python: PyJWT.decode(token, options={'verify_signature': False}) om te lezen, geef een sleutel mee om te verifiëren. Go: jwt.ParseUnverified(token, claims) voor alleen lezen, jwt.Parse(token, keyFunc) voor verificatie. Gebruik in elke taal nooit options={'verify_signature': False} in productiecode — dat is wat deze webtool bewust doet voor debuggen, en het is alleen veilig bij inspecteren, niet bij authenticeren.
Wat is de maximale grootte van een JWT?
De JWT-standaard legt geen harde grens op, maar headers in de meeste webservers zijn standaard beperkt tot ongeveer 8 KB. Houd tokens onder de 4 KB zodat ze comfortabel passen in Authorization-headers en cookies. Als je token groter is, stop je waarschijnlijk te veel claims in de payload — verplaats omvangrijke data naar een ondoorzichtig sessie-ID en haal het op via je backend wanneer nodig. Grote JWT's kosten ook bandbreedte bij elk API-verzoek, want ze worden elke keer meegestuurd.
Ik heb mijn token geplakt maar krijg 'Ongeldig JWT-formaat' — wat gaat er mis?
Een geldig JWT heeft precies drie delen gescheiden door punten: header.payload.signature. Veelvoorkomende oorzaken: (1) je hebt per ongeluk alleen het payload-segment gekopieerd, (2) er zijn spaties of regeleinden in het midden geplakt, (3) het token is afgekapt tijdens overdracht (komt vaak voor bij regelafbreking in de terminal), (4) het token is een JWE waarbij het formaat header.encryptedKey.iv.ciphertext.tag is (vijf segmenten), of (5) het token is URL-geëncodeerd en je moet het eerst URL-decoderen. Controleer de ruwe waarde die je API heeft teruggegeven — de meeste editors tonen onzichtbare tekens als je er met de muis overheen beweegt.
Kan ik een JWT decoderen zonder de geheime sleutel?
Ja — de header en payload zijn via Base64URL geëncodeerd, niet versleuteld. Iedereen met het token kan de claims lezen zonder enige sleutel. Dit is by design: de payload is bedoeld om leesbaar te zijn zodat de ontvanger autorisatiebeslissingen kan nemen. De geheime of publieke sleutel is alleen nodig om te verifiëren dat het token niet is gewijzigd. Daarom mag je nooit gevoelige gegevens (wachtwoorden, private sleutels, PII buiten wat de ontvanger al weet) in een JWT-payload stoppen.
Mijn JWT werkt in Postman maar mijn backend wijst hem af — hoe debug ik dit?
Decodeer het token hier en controleer: (1) exp — ligt het in de toekomst ten opzichte van de klok van de server? Klokafwijking op de server is een veelvoorkomende oorzaak. (2) iss / aud — komen ze exact overeen met wat je backend verwacht? Een mismatch op aud is de meest voorkomende fout-negatief. (3) alg — staat dat algoritme op de toegestane lijst in je verificatiecode? Een HS256-token mislukt tegen een bibliotheek die alleen voor RS256 is geconfigureerd. (4) kid — als je sleutelrotatie gebruikt, is de key ID in de header aanwezig in je JWKS? (5) signature — heb je de juiste geheime of publieke sleutel geplakt? Deze decoder toont (1), (2), (3) en (4) in de header- en payload-weergaven zodat je ze snel kunt uitsluiten.

Gerelateerde tools

Alle tools bekijken →