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
Claims förklarade
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
- Klistra in token i rutan Kodad token. Ett inledande
Bearerfrån en Authorization-header ignoreras. - Header och payload avkodas direkt och visas som formaterad JSON.
- Läs tabellen Claims förklarade:
exp,iatochnbfomvandlas till datum med tider som ”går ut om” / ”gick ut för”. - Kontrollera statusfältet för utgångsproblem och varningarna för riskabla inställningar som
alg: none. - 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
| Claim | Betydelse |
|---|---|
iss | Utfärdare: vem som skapade och signerade token |
sub | Subjekt: oftast användar-ID:t |
aud | Mottagare: vilket API token är avsedd för |
exp | Utgångstid, i sekunder sedan Unix-epoken |
nbf | Inte giltig före denna tid |
iat | Tidpunkt för utfärdande |
jti | Unikt 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?
Verifierar verktyget JWT-signaturen?
Varför visas min token som utgången?
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?
Varför är alg ”none” farligt?
alg: none och bör bara acceptera exakt den algoritm de förväntar sig.