Codificatore / decodificatore JWT

Cosa significa «decodificare un JWT»?

Decodificare un JWT (« jwt decode », « decode jwt online ») consiste nel tagliare la stringa ai due punti, poi nel decodificare ogni segmento in Base64URL per ritrovare il JSON originale. Non serve alcuna chiave: header e payload sono semplicemente codificati, non cifrati. È esattamente l'intento dietro « jwt payload decoder » o « decode jwt without verify » — vedere cosa contiene il token, senza pretendere che sia autentico.

Attenzione a ben distinguere le due operazioni. Leggere un JWT non prova nulla: chiunque può fabbricare un token con un payload allettante e firmarlo con il proprio secret. Verifica la firma dimostra che il contenuto non è stato modificato da terzi. Un decodificatore che mostra « admin: true » senza controllo della firma ti racconta una storia, non un fatto.

I tre segmenti di un JWT

La stringa si divide esattamente in tre parti separate da punti: header.payload.signature. L'header contiene almeno alg e typ, a volte kid per indicare quale chiave è stata usata. Il payload contiene i claim, queste coppie chiave-valore il cui registro è tenuto dall'IANA. La firma copre i due primi segmenti concatenati esattamente come scritti — la minima modifica di uno spazio o di un carattere fa fallire il confronto.

Tutta la difficoltà deriva dal fatto che questi segmenti sono in Base64URL e non in Base64: il segno più diventa un trattino, la barra obliqua diventa un underscore e il padding = sparisce. Un decodificatore Base64 classico fallirà quindi su un JWT valido. La tabella « Base64URL contro Base64 classico » della scheda riferimento mostra proprio queste sostituzioni.

Come verificare una firma: HS256, RS256, ES256

Per un algoritmo HMAC — HS256, HS384, HS512 — lo stesso secret serve per firmare e verificare: lo strumento ricalcola HMAC(secret, base64url(header) + "." + base64url(payload)) e confronta il risultato con la firma trasportata. È il caso più diffuso, e anche il più pericoloso: qualsiasi servizio che possiede il secret può emettere un token. Un secret di meno di 32 byte, riusato tra ambienti, basta per compromettere tutta la catena.

Per gli algoritmi asimmetrici — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — per verificare serve solo la chiave pubblica, così puoi controllare un token emesso da terzi senza mai condividerne il secret di firma. Incolla la chiave in formato PEM -----BEGIN PUBLIC KEY----- (SPKI); il risultato grezzo di un export OpenSSL è direttamente utilizzabile. Per ES256 la firma è in formato r||s grezzo, quello che WebCrypto si aspetta.

Infine bisogna diffidare dell'alg confusion : se il tuo servizio si aspetta RS256 ma accetta un token il cui header dichiara HS256, un attaccante firmerà con la chiave pubblica — diventata chiave HMAC — e supererà la verifica. Fissa l'algoritmo atteso lato server, non leggerlo mai dal token stesso.

exp, iat, nbf: i timestamp che ingannano

Questi tre claim sono secondi Unix, senza millisecondi e senza fuso orario: iat a 1516239022 significa 2018-01-17T21:30:22Z. Due errori si ripetono di continuo: confrontare con una data in millisecondi (valore diecimila volte troppo grande) e interpretare un timestamp in locale anziché in UTC. La scheda « Scadenza » converte in entrambe le direzioni, mostra l'ISO 8601, la data locale e il tempo rimasto o trascorso — per individuare all'istante un token « già scaduto » al secondo di orologio più vicino.

Prolungare la durata di validità non alza il livello di sicurezza: un exp spostato cambia il valore mostrato, non la firma. Se devi rilasciare di nuovo, rifirma il token con il secret o la chiave privata — è esattamente il ruolo della scheda « Codifica ».

Base64URL: perché i decodificatori classici falliscono

Base64URL (RFC 4648 §5) usa l'alfabeto A-Z a-z 0-9 - _ e non ammette padding. Un payload di 20 caratteri produce spesso una lunghezza non multipla di quattro dopo la rimozione del = : è normale, non un corrompimento. I caratteri - e _ sono ambigui per un occhio umano, ed è questo che spiega metà dei « token rotti » segnalati. Il nostro decodificatore accetta entrambi gli alfabeti, maiuscole e minuscole miste, il padding opzionale e un prefisso Bearer.

Sicurezza: ciò che un JWT non fa

Un JWT non offre né riservatezza né revoca. Il payload è leggibile da tutti: mai un'e-mail, un ruolo interno o un dato personale che non accetteresti di inviare in chiaro. E un token firmato resta valido fino a exp anche dopo la disconnessione — serve una lista di revoca, un jti monitoraggio lato server o durate di validità corte con refresh token. Una buona prassi: exp corto (da 10 a 15 minuti), iat controllato, nbf allineato su iat, aud e iss verificati alla ricezione.

Consigliato per

Sviluppatori back-end e front-end (OAuth 2.0, OpenID Connect, API REST), integrator e DevOps (infrastruttura di identità, JWKS, rotazione delle chiavi), tester e pentester (riscrittura di claim, alg confusion, scadenza), amministratori di sistemi (debug di un 401 inspiegabile), studenti (capire Base64URL e WebCrypto) e chiunque abbia bisogno di un decodificatore JWT online veloce, completo e riservato — con in più il codificatore/decodificatore Base64, il codificatore/decodificatore URL e il formattatore JSON.

Decodificatore JWT 100 % locale: il tuo token non lascia mai il tuo computer

A differenza dei decodificatori JWT online classici, nessuna stringa viene trasmessa: decodifica, verifica della firma e codifica avvengono interamente nel tuo browser via WebCrypto, senza librerie di terze parti né richieste di rete. È così che puoi ispezionare un token di sessione reale, una chiave di staging o un token di servizio interno senza rischi, anche offline o su una rete pubblica. Cronologia e ultima digitazione restano in locale (localStorage) e sul tuo dispositivo.

La licenza Premium Volade aggiunge una sincronizzazione cloud facoltativa, crittografata, indipendente dallo strumento — il resto resta gratuito e illimitato, senza registrazione.