Encoders & Utilities

JWT Decoder

Decodifica header e payload JWT in locale.

JWT token Paste a JWT — we will split it into header, payload, and signature.

Informazioni su questo strumento

Un JSON Web Token (RFC 7519) è composto da tre segmenti codificati in Base64url uniti da punti: header, payload e firma. JWT Decoder divide il token, decodifica i primi due segmenti in JSON, li formatta e calcola le claim relative al tempo (iat, exp, nbf) come timestamp leggibili. Le claim registrate standard (iss, sub, aud, jti) sono etichettate con il loro significato. La decodifica viene eseguita interamente nel tuo browser — il tuo token non lascia mai la pagina.

L'header ti dice l'algoritmo di firma (alg: HS256, RS256, ES256, ecc.) e l'opzionale kid (key ID). Il payload contiene le claim dell'applicazione — ID utente, ruoli, scadenza. La firma è mostrata come un blob Base64; deliberatamente non la verifichiamo su questa pagina perché la verifica richiede il segreto dell'issuer o la chiave pubblica, che non dovrebbero mai essere incollati in uno strumento di terze parti. Il token è trattato solo come dati.

Quando usare questo strumento

Leggere un token dal tuo servizio. Ispeziona quali claim emetti effettivamente — individua rapidamente campi mancanti, audience sbagliate o default sorprendenti.
Debug di risposte "401 Unauthorized". Verifica scadenza, issuer, audience e scope rispetto a ciò che il server si aspetta.
Verifica di un'integrazione di terze parti. Quando un provider OAuth ti consegna un ID token, decodifica il payload per vedere quali claim utente includono.
Individuare confusione di algoritmi. Se alg è none o differisce inaspettatamente tra token, la tua libreria di auth è probabilmente mal configurata.

Perché non validiamo le firme

La verifica della firma JWT richiede il segreto (per gli algoritmi HMAC) o la chiave pubblica dell'issuer (per RSA/ECDSA). Incollare uno dei due in uno strumento web è un errore di sicurezza — il segreto comprometterebbe ogni token emesso; la chiave pubblica, pur meno sensibile, può comunque essere privata. Il decoder conferma la struttura e rivela le claim; per la verifica reale, usa l'SDK fornito con la tua libreria di auth (jsonwebtoken, pyjwt, jose) dentro il tuo codice.

Domande frequenti

È sicuro incollare il mio JWT qui?

La decodifica avviene interamente in JavaScript nel tuo browser — non viene fatta alcuna chiamata di rete, non avviene alcun log lato server. Detto questo, i JWT in produzione devono essere trattati come credenziali: non incollare un token long-lived da un servizio che non controlli in nessuno strumento di terze parti, incluso il nostro. Per token di dev/staging o token scaduti, decodificarli qui va bene.

Perché la firma è mostrata ma non verificata?

Perché la verifica richiede la chiave di firma, e incollare una chiave di firma in uno strumento web sarebbe un errore grave. La firma è mostrata come Base64 così puoi vedere che esiste e ha la lunghezza giusta per l'algoritmo, ma validarla effettivamente contro un segreto HMAC (HS256) o una chiave pubblica (RS256/ES256) appartiene dentro la tua applicazione, non a uno strumento browser.

Cosa significa "alg: none"?

Un JWT non firmato. L'header dichiara esplicitamente che non è stato applicato alcun algoritmo, quindi il segmento di firma è vuoto. alg: none esiste nella specifica ma non dovrebbe mai apparire in produzione — è la causa principale della famosa vulnerabilità "JWT none-algorithm" dove una libreria accetta none come valido. Se lo vedi in un token reale da un servizio reale, è un bug serio.

Qual è la differenza tra exp, iat e nbf?

iat (issued-at) è quando il token è stato creato. nbf (not-before) è il primo momento in cui il token può essere usato — di solito uguale a iat ma può essere nel futuro per l'attivazione ritardata. exp (expiration) è quando il token smette di essere valido. Tutti e tre sono timestamp Unix in secondi. Un verifier ben educato controlla nbf ≤ ora ≤ exp su ogni richiesta.