JWT Decoder
Incolla un JSON Web Token per leggerne header e payload, vedere quando scade e capire ogni claim. Il tuo token non lascia mai il browser.
Funziona nel browserNessuna registrazioneNessun caricamento
Decodificare non significa verificare. Chiunque può leggere header e payload di un JWT, perché sono solo codificati in base64url. Questo strumento mostra ciò che il token dichiara; non prova che il token sia autentico. Verifica sempre la firma sul tuo server.
Header
Payload
Claim spiegati
Verifica firma (facoltativo, HS256/HS384/HS512)
Controlla una firma HMAC con il secret che inserisci, usando la Web Crypto API del browser. Il secret non lascia mai questa pagina. I token RSA/ECDSA richiedono la chiave pubblica dell'emittente e qui non vengono verificati.
Come usare Decoder JWT
- Incolla il token nel riquadro Token codificato. Un eventuale
Beareriniziale preso da un header Authorization viene ignorato. - Header e payload vengono decodificati all'istante e mostrati come JSON formattato.
- Leggi la tabella Claim spiegati:
exp,iatenbfvengono convertiti in date con indicazioni come “scade tra” / “scaduto da”. - Controlla la barra di stato per i problemi di scadenza e gli avvisi per impostazioni rischiose come
alg: none. - Se vuoi, inserisci il secret condiviso per verificare in locale una firma HS256, HS384 o HS512.
Cosa c'è dentro un JWT?
Un JSON Web Token (RFC 7519) è formato da tre stringhe base64url unite da punti: header.payload.signature. L'header indica l'algoritmo di firma (alg) e il tipo di token. Il payload contiene i claim, ad esempio chi è l'utente e quando scade il token. La firma viene calcolata sulle prime due parti con un secret o una chiave privata.
Decodificare non significa verificare
Header e payload sono solo codificati, non cifrati, quindi chiunque abbia il token può leggerli. Per questo non dovresti mai inserire password o segreti nel payload di un JWT. La decodifica ti dice cosa un token afferma. La verifica della firma, di solito sul server API con una libreria come jose o PyJWT, dimostra chi l'ha emesso e che non è stato modificato. Un server deve anche controllare exp, nbf, iss e aud e rifiutare algoritmi inattesi.
Promemoria dei claim registrati
| Claim | Significato |
|---|---|
iss | Issuer (emittente): chi ha creato e firmato il token |
sub | Subject (soggetto): di solito l'ID utente |
aud | Audience (destinatari): a quale API è destinato il token |
exp | Scadenza, in secondi dall'epoch Unix |
nbf | Non valido prima di questo momento |
iat | Momento di emissione |
jti | ID univoco del token, utile per le liste di revoca |
Debug degli errori “token expired”
Se un'API rifiuta un token che sembra nuovo, confronta exp e nbf con l'orologio del server. Piccoli sfasamenti tra gli orologi delle macchine sono comuni, quindi la maggior parte delle librerie concede 30-60 secondi di tolleranza. Controlla anche che exp sia in secondi: un valore in millisecondi è un bug frequente e sposta la scadenza di migliaia di anni nel futuro.
Domande frequenti
È sicuro incollare qui un JWT di produzione?
Questo strumento verifica la firma del JWT?
Perché il mio token risulta scaduto?
exp è nel passato rispetto all'orologio del tuo computer. Richiedi un nuovo token o rinnovalo con il refresh token. Se gli orari sembrano sbagliati, controlla eventuali sfasamenti dell'orologio o un valore di exp scritto in millisecondi.Che differenza c'è tra JWT, JWS e JWE?
Perché alg “none” è pericoloso?
alg: none e accettare solo l'algoritmo specifico che si aspettano.