JWT Decoder

Klistra in en JSON Web Token för att läsa dess header och payload, se när den går ut och förstå varje claim. Din token lämnar aldrig webbläsaren.

Körs i din webbläsareIngen registreringInget laddas upp

Avkodning är inte verifiering. Vem som helst kan läsa en JWT:s header och payload, eftersom de bara är base64url-kodade. Verktyget visar vad token påstår; det bevisar inte att token är äkta. Verifiera alltid signaturen på din server.

Header

Payload


      

Verifiera signatur (valfritt, HS256/HS384/HS512)

Kontrollerar en HMAC-signatur med en hemlighet du anger, via webbläsarens Web Crypto API. Hemligheten lämnar aldrig sidan. RSA-/ECDSA-tokens kräver utfärdarens publika nyckel och verifieras inte här.

Så använder du JWT-avkodare

  1. Klistra in token i rutan Kodad token. Ett inledande Bearer från en Authorization-header ignoreras.
  2. Header och payload avkodas direkt och visas som formaterad JSON.
  3. Läs tabellen Claims förklarade: exp, iat och nbf omvandlas till datum med tider som ”går ut om” / ”gick ut för”.
  4. Kontrollera statusfältet för utgångsproblem och varningarna för riskabla inställningar som alg: none.
  5. Ange vid behov den delade hemligheten för att verifiera en HS256-, HS384- eller HS512-signatur lokalt.

Vad finns i en JWT?

En JSON Web Token (RFC 7519) består av tre base64url-strängar sammanfogade med punkter: header.payload.signature. Headern anger signeringsalgoritmen (alg) och tokentypen. Payloaden innehåller claims, till exempel vem användaren är och när token går ut. Signaturen beräknas över de två första delarna med en hemlighet eller privat nyckel.

Avkodning är inte verifiering

Header och payload är bara kodade, inte krypterade, så vem som helst som har token kan läsa dem. Därför ska du aldrig lägga lösenord eller hemligheter i en JWT-payload. Avkodning visar vad en token påstår. Att verifiera signaturen, normalt på din API-server med ett bibliotek som jose eller PyJWT, bevisar vem som utfärdat den och att den inte har ändrats. En server måste också kontrollera exp, nbf, iss och aud och avvisa oväntade algoritmer.

Lathund för registrerade claims

ClaimBetydelse
issUtfärdare: vem som skapade och signerade token
subSubjekt: oftast användar-ID:t
audMottagare: vilket API token är avsedd för
expUtgångstid, i sekunder sedan Unix-epoken
nbfInte giltig före denna tid
iatTidpunkt för utfärdande
jtiUnikt token-ID, användbart för spärrlistor

Felsöka ”token expired”-fel

Om ett API avvisar en token som ser färsk ut, jämför exp och nbf med serverns klocka. Små tidsavvikelser mellan maskiner är vanliga, så de flesta bibliotek tillåter 30–60 sekunders marginal. Kontrollera också att exp anges i sekunder: ett värde i millisekunder är en vanlig bugg och lägger utgångstiden tusentals år framåt.

Vanliga frågor

Är det säkert att klistra in en JWT från produktion här?
Avkodningen sker helt i din webbläsare med JavaScript. Token laddas inte upp, loggas inte och sparas inte. Som med alla inloggningsuppgifter bör du ändå hantera aktiva tokens varsamt och hellre använda utgångna tokens eller testtokens när du delar skärmdumpar.
Verifierar verktyget JWT-signaturen?
Inte vid enbart avkodning. Du kan verifiera HS256-, HS384- och HS512-tokens genom att ange den delade hemligheten; HMAC beräknas lokalt med Web Crypto API. RS256- och ES256-tokens måste verifieras med utfärdarens publika nyckel på din server.
Varför visas min token som utgången?
Claimen exp ligger i det förflutna jämfört med datorns klocka. Begär en ny token eller förnya den med din refresh token. Om tiderna ser fel ut, kontrollera om klockorna går olika eller om exp är angivet i millisekunder.
Vad är skillnaden mellan JWT, JWS och JWE?
JWT är formatet för claims. En JWS är en signerad JWT med tre delar, vilket är det som verktyget avkodar. En JWE är en krypterad JWT med fem delar; dess payload kan inte läsas utan dekrypteringsnyckeln.
Varför är alg ”none” farligt?
En osignerad token kan förfalskas av vem som helst. Servrar måste avvisa alg: none och bör bara acceptera exakt den algoritm de förväntar sig.

Relaterade verktyg