Decodificatore JWT (header, payload, firma, scadenza)
Incolla un JWT per decodificare istantaneamente header e payload come JSON. Riconosce le claim standard (iat, exp, nbf) e converte i timestamp Unix in ISO 8601. Segnala i token scaduti o non ancora validi.
Decodificato interamente nel tuo browser. Il token non viaggia mai in rete.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "1234567890",
"name": "Jane Doe",
"iat": 1730000000,
"exp": 4886000000
}- Firma presente
- ✓
- Emesso il (iat)
- 2024-10-27T03:33:20.000Z
- Scade il (exp)
- 2124-10-30T22:13:20.000Z
Come funziona
Come è fatto un JWT
Un JWT è composto da tre segmenti codificati in Base64url uniti da punti: header.payload.firma. Ogni segmento è un oggetto JSON codificato per la trasmissione sicura negli URL. L'header dichiara l'algoritmo di firma, il payload contiene le claim (soggetto, scadenza, dati personalizzati), e la firma consente al destinatario di verificare l'integrità se possiede la chiave.
Questo decodificatore legge solo i primi due segmenti. La firma è il terzo segmento ma verificarla richiede la chiave segreta/pubblica — un'operazione separata che non eseguiamo qui.
Claim standard da conoscere
iss (issuer): chi ha creato il token. iat (issued at): quando, come timestamp Unix. exp (expiry): quando smette di essere valido, anch'esso Unix. nbf (not before): il primo momento in cui dovrebbe essere accettato. sub (subject): l'entità che rappresenta, spesso un ID utente. aud (audience): per chi è il token, di solito un URL di servizio.
Non tutti sono obbligatori; i JWT minimali hanno spesso solo sub + iat + exp. Le claim personalizzate sono tutto il resto — convivono con quelle standard nel payload.
Perché decodificare ≠ verificare
Chiunque può decodificare un JWT — header e payload sono semplicemente JSON codificato in Base64. Ecco perché diciamo 'non mettere mai segreti nel payload': sono effettivamente pubblici.
La verifica significa controllare la firma rispetto alla chiave segreta (HMAC) o alla chiave pubblica (RSA/ECDSA). Senza verifica, non puoi fidarti di nessuna claim nel payload — un attaccante può creare qualsiasi payload voglia.
Usa questo strumento per ispezionare i token durante il debug. Usa una libreria JWT sul tuo server per verificarli in produzione.
Domande frequenti
›Posso verificare la firma qui?
No — la verifica richiede la chiave segreta o pubblica, che non dovrebbe mai lasciare un ambiente affidabile. Usa una libreria JWT lato server (jsonwebtoken per Node, PyJWT per Python, ecc.).
›Il token lascia il mio browser?
Mai. La decodifica viene eseguita localmente; non abbiamo un endpoint server per riceverlo.
›Perché il mio token risulta 'non valido'?
Comune: copia-incolla ha aggiunto/rimosso spazi bianchi, manca uno dei tre segmenti, o un segmento è Base64url malformato. Rimuovi gli spazi e riprova.
›Cos'è Base64url vs Base64?
Base64url sostituisce '+' con '-', '/' con '_', e rimuove il padding '=' così la stringa codificata è sicura negli URL e negli header HTTP. I JWT usano sempre Base64url.
›Perché il mio payload Unicode mostra testo incomprensibile?
Decodifichiamo UTF-8, che è lo standard. Se il payload era codificato diversamente, JSON.parse potrebbe fallire. La maggior parte degli emittenti JWT codifica correttamente UTF-8.
›HS256 è sicuro?
Se il segreto è sufficientemente lungo (≥256 bit) e mantenuto segreto, sì. Le vulnerabilità comuni di HS256 sono segreti deboli e l'accettazione di token con alg='none'. Usa segreti casuali di ≥32 caratteri e rifiuta esplicitamente 'none'.
›Perché preferire RS256 a HS256?
RS256 (RSA asimmetrico) permette di pubblicare una chiave pubblica per la verifica mantenendo privata la chiave di firma. HS256 (HMAC simmetrico) richiede la condivisione del segreto con ogni verifier. Per architetture multi-servizio, RS256 è più sicuro.
›Posso decodificare token enormi?
Il limite pratico è circa 10 MB di input; oltre, il browser potrebbe rallentare. I JWT di solito sono sotto i 4 KB; se il tuo è più grande, considera se stai memorizzando troppo nelle claim.
Strumenti correlati
Ultimo aggiornamento: