JWT-debugger / -dekoder

Lim inn et hvilket som helst JWT for å dekode de tre punktumsadskilte delene — base64url-headeren, nyttelasten og signaturen vises som pent formatert JSON, med registrerte krav (exp, iat, nbf og lignende) omregnet til lokal tid. Deretter kan signaturen verifiseres med WebCrypto-API-et: HMAC (HS256/384/512) med en hemmelighet, eller RSA/ECDSA (RS256/384/512, ES256/384/512) med en PEM-offentlig nøkkel. Et eksempel-HS256-token er ett klikk unna for å eksperimentere. Alt kjøres lokalt — tokens, hemmeligheter og nøkler sendes aldri noe sted.
JWT-token Format: header.nyttelast.signatur (tre base64url-segmenter).
Dekodet
Header
Nyttelast
Signatur (rå base64url-segment)
Advarsel: dette tokenet angir alg:none, som betyr at det ikke er signert. Ekte tjenester må avvise usignerte tokens — behandle det som ikke pålitelig.
Registrerte krav
KravVerdiTolkning
Verifiser signatur
Hemmelighet
crypto.subtle er ikke tilgjengelig i denne konteksten, så signaturverifisering er deaktivert. Åpne siden over https: eller fra en lokal fil for å aktivere den. Dekoding fungerer fortsatt.
Slik leser man resultatet: headeren inneholder vanligvis alg (signeringsalgoritmen) og typ. Registrerte krav som vises med lokal tid, er iat (utstedt), nbf (ikke før) og exp (utløp) — et rødt merke betyr at tokenet er utløpt, gult betyr at det utløper innen 24 timer. Signaturverifisering beregner den samme MAC-en som utstederen ville ha beregnet, eller sjekker den offentlige RSA/ECDSA-nøkkelen som limes inn, og merker deretter tokenet GYLDIG eller UGYLDIG. Bare algoritmer som er implementert i nettleserens WebCrypto-lag, kan verifiseres; alt annet rapporteres som ikke støttet i stedet for å gjettes.

Vanlige registrerte krav: sub (subject) er brukeren eller enheten tokenet gjelder — i eksempelet er det bare en numerisk ID, men tjenester legger ofte e-post, brukernavn eller UUID her. iss angir utstederen, aud angir tiltenkt mottaker, og jti er en unik token-ID som brukes for å hindre gjentatt bruk (replay). Disse kravene er ikke kryptert; alle som har tokenet, kan lese dem, så passord eller hemmeligheter skal aldri legges i en JWT-nyttelast.

Personvern: dekoding og verifisering skjer helt på denne siden med WebCrypto-API-et — tokenet, hemmeligheten og eventuelle offentlige nøkler sendes aldri. For et alg:none-token viser siden en tydelig advarsel: uinnpakkede tokens skal aldri godtas av et ekte API.