JWT-parser

Decodeer en inspecteer JSON Web Tokens (JWT) met realtime validatie. Bekijk header-, payload- en handtekeninginformatie veilig in uw browser.

Definitie: Een JSON Web Token bestaat uit drie Base64URL-gecodeerde delen — header, payload, handtekening — verbonden door punten. De header noemt het handtekeningsalgoritme, en de handtekening wordt volgens RFC 7519 geverifieerd met het sleutelmateriaal van dat algoritme.

IETF RFC 7519 Laatst bijgewerkt: 2026-09

Hoe gebruik je de JWT-parser

1

Token plakken

Paste your JWT token in the input area

2

Automatisch decoderen

Token automatically decodes on paste

3

Onderdelen inspecteren

View header, payload, and signature data

4

Status controleren

Controleer de geldigheid en vervaltijd van het token

JWT-tokens begrijpen

Wat is een JWT?

Een JSON Web Token (JWT) is een compact, URL-veilig middel om claims weer te geven die tussen twee partijen worden overgedragen. Het bestaat uit drie delen — header, payload en handtekening —, gescheiden door punten en base64url-geëncodeerd.

  • • Header: Contains token type and signing algorithm
  • • Payload: Contains claims or user data
  • • Signature: Verifies token wasn't tampered with
  • • Stateless: No server-side session storage needed

Waarom JWT's parsen?

Het parsen van JWT's is essentieel voor het debuggen van authenticatieproblemen, het verifiëren van token-inhoud, het controleren van verlooptijden en het begrijpen van welke data in tokens wordt overgedragen.

  • • Debugging: Inspect token contents during development
  • • Security: Verify token structure and claims
  • • Expiration: Check token validity period
  • • Development: Understand authentication flow

Standaard JWT-claims-referentie

Geregistreerde claimnamen volgens RFC 7519 die je in vrijwel elke token-payload tegenkomt.

Claim Volledige naam Betekenis
issUitgeverWie het token heeft aangemaakt en ondertekend
subOnderwerpOver wie het token gaat — meestal de gebruikers-ID
audDoelgroepVoor wie het token bedoeld is (een client of API)
expVervaltijdUnix-timestamp waarna het token afgewezen moet worden
nbfNiet voorUnix-timestamp waarvoor het token ongeldig is
iatUitgegeven opUnix-timestamp van het moment waarop het token is aangemaakt
jtiJWT-IDUnieke identificatie, nuttig voor intrekkingslijsten

Veelgebruikte JWT-algoritmes

  • • HS256 (HMAC + SHA-256): Symmetrisch — één gedeeld geheim ondertekent en verifieert. Eenvoudig, maar iedereen met het geheim kan tokens vervalsen.
  • • RS256 (RSA + SHA-256): Asymmetrisch — de privésleutel ondertekent, de publieke sleutel verifieert. De standaardkeuze voor gedistribueerde systemen.
  • • ES256 (ECDSA + SHA-256): Asymmetrisch zoals RS256, maar met veel kortere handtekeningen — een goede moderne standaardkeuze.
  • • geen: Niet-ondertekend token. Moet door elke serieuze verifier afgewezen worden; historisch de bron van kritieke bypass-kwetsbaarheden.

Veiligheidsnotities

  • • Plak nooit productietokens in onbekende tools. Deze parser draait volledig in je browser (controle: hij werkt offline), maar dat geldt niet voor elke site.
  • • Een JWT is niet versleuteld. De payload is alleen base64url-gecodeerd — iedereen met het token kan hem lezen. Bewaar nooit geheimen in claims.
  • • Decoderen is niet verifiëren. Een structuur die geldig oogt, zegt niets over de handtekening. Voor verificatie is de sleutel nodig, en die verlaat nooit je auth-server.
  • • Controleer exp aan de serverkant. Verlopen tokens afwijzen is de taak van de verifier, niet van de client.

Wanneer ontwikkelaars een JWT-parser gebruiken

401- en 403-reacties debuggen

Controleer of het token daadwerkelijk de verwachte scopes, rollen of vervaldatum bevatte voordat u de server de schuld geeft.

OAuth- en OIDC-tokens inspecteren

Decodeer een id_token of access_token en bevestig dat iss, aud en sub overeenkomen met uw applicatieconfiguratie.

Ondersteuning en probleemoplossing

Controleer aan de hand van een screenshot welke claims een gebruiker daadwerkelijk ontving, zonder lokale tools op te zetten.

Leren hoe JWT's werken

Plak voorbeeldtokens en zie hoe header, payload en handtekening samenhangen.

Direct decoderen

JWT automatisch decoderen bij het plakken, met kleurgecodeerde secties.

100% Privé

Alle decodering gebeurt in uw browser. Tokens verlaten uw apparaat nooit.

Volledig gratis

Geen registratie, geen limieten. Parseer JWT-tokens gratis op elk moment.

Veelgestelde vragen over de JWT-parser

Is het veilig om een JWT in deze tool te plakken?

Ja. Het decoderen draait volledig in je browser zonder netwerkverzoeken — je kunt dit controleren door de internetverbinding te verbreken en de pagina opnieuw te laden. Toch geldt als goede gewoonte: plak productietokens nergens.

Verifieert het parsen van een JWT de handtekening?

Nee. Parsen doet alleen een base64url-decode van de header en payload. Voor het verifiëren van de handtekening is de ondertekeningssleutel nodig (HMAC-geheim of publieke sleutel), en die heeft alleen jouw auth-server.

Waarom kan iedereen mijn JWT-payload lezen?

JWT-payloads zijn gecodeerd, niet versleuteld. Iedereen met het token kan de claims decoderen en lezen — dat is bewust zo ontworpen. Bewaar nooit geheimen of gevoelige gegevens in een JWT-payload.

Hoe weet ik wanneer een token verloopt?

Controleer de claim exp — een Unix-timestamp waarna het token afgewezen moet worden. Deze parser markeert de tokenstatus (actief, verlopen of nog niet geldig) automatisch op basis van exp en nbf.

Wat is het verschil tussen HS256 en RS256?

HS256 is symmetrisch: één gedeeld secret wordt zowel voor ondertekening als verificatie gebruikt, dus iedereen die tokens kan verifiëren, kan ze ook vervalsen. RS256 is asymmetrisch: een privésleutel ondertekent en een publieke sleutel verifieert — veiliger wanneer meerdere services tokens moeten valideren. Geef de voorkeur aan RS256 of ES256, tenzij u een specifieke reden heeft om dat niet te doen.

Mijn tokenheader zegt "alg": "none" — is dat een probleem?

Het betekent dat het token niet ondertekend is. Dat is een geldige JWT-structuur, maar een verificateur mag het nooit accepteren: de klassieke JWT-kwetsbaarheid was aanvallers die alg op none zetten om handtekeningcontroles te omzeilen. Accepteert uw backend niet-ondertekende tokens, beschouw dat dan als een securitybug.