Codificatore e decodificatore Base64 / URL / JWT

Codifica e decodifica Base64 o URL ed esamina intestazione e payload di un JWT nel browser.

Testo o JWT

Output

Come si usa

Incolla o digita il contenuto nel riquadro «Testo o JWT»: testo semplice da codificare, una stringa Base64 o con codifica percentuale da decodificare, oppure un JWT da esaminare.
Fai clic su «Codifica Base64» o «Decodifica Base64» per convertire tra testo e Base64, oppure su «Codifica URL» o «Decodifica URL» per aggiungere o rimuovere la codifica percentuale. Il risultato, o un messaggio di errore, compare nel riquadro «Output».
Per esaminare un token, incollalo con o senza il prefisso Bearer e fai clic su «Decodifica JWT». L’intestazione e il payload compaiono come JSON con rientro, e gli eventuali claim iat, nbf ed exp del payload sono elencati in «Claim temporali del JWT», con i valori numerici convertiti in UTC e nella tua ora locale.
Fai clic su «Copia il risultato» per copiare l’output. Per invertire una codifica, incolla il testo codificato nel riquadro «Testo o JWT» e fai clic sul pulsante di decodifica corrispondente. Decodificare e poi codificare di nuovo può non restituire esattamente l’originale: il Base64 URL-safe o senza padding torna nell’alfabeto standard, con il padding = dove serve, e «Codifica URL» trasforma in %2B un + lasciato da «Decodifica URL».

Domande frequenti

Il testo o il token che incollo viene inviato da qualche parte?

No. La codifica e la decodifica avvengono nel browser con JavaScript e ciò che inserisci non viene inviato a LeedyBox. Un JWT è spesso usato come credenziale di accesso e può funzionare per chiunque lo possieda finché non scade o non viene revocato, quindi tratta un token ancora valido come una password e non condividerlo in screenshot o chat.

Perché «Decodifica Base64» dice che i dati non sono testo UTF-8 valido?

«Decodifica Base64» mostra i byte decodificati come testo UTF-8 e si ferma con questo errore quando non sono UTF-8 valido, per esempio con immagini PNG o JPEG, con la maggior parte dei PDF e con i dati compressi, e spesso con testo salvato in un’altra codifica come Latin-1 o Shift_JIS. Lo strumento non salva i byte decodificati come file, quindi usalo per Base64 che contiene testo. Un data URI come data:image/png;base64,... viene rifiutato come Base64 non valido, perché i due punti, il punto e virgola e la virgola non sono caratteri Base64.

Supporta il Base64 URL-safe e i valori senza padding?

Sì, in decodifica: «Decodifica Base64» accetta l’alfabeto standard (+ e /) e l’alfabeto URL-safe (- e _), con o senza padding =, e ignora spazi e a capo. «Codifica Base64» produce l’alfabeto standard con padding; per la forma URL-safe usata nei JWT, sostituisci + con -, / con _ e rimuovi i segni = finali. Il testo viene codificato in UTF-8 esattamente come inserito, quindi uno spazio o un a capo finale cambia il risultato, e gli a capo nel riquadro vengono codificati come LF.

Devo incollare un URL intero in «Codifica URL»?

Di solito no. «Codifica URL» funziona come encodeURIComponent di JavaScript: applica la codifica percentuale a tutti i caratteri tranne A–Z, a–z, 0–9 e - _ . ! ~ * ' ( ), quindi vengono codificati anche i caratteri / ? & = : e # che danno struttura a un URL. Usalo per una sola parte, come il valore di un parametro di query. Gli spazi diventano %20 e i caratteri non ASCII vengono codificati come i loro byte UTF-8, quindi é diventa %C3%A9.

Perché i segni più non diventano spazi, e quando «Decodifica URL» segnala un errore?

«Decodifica URL» funziona come decodeURIComponent di JavaScript: decodifica le sequenze di escape %XX e lascia invariato il +, perché nella sintassi generale degli URL (RFC 3986) il + non indica uno spazio. I dati dei moduli HTML (application/x-www-form-urlencoded), usati da molte query string, codificano gli spazi come +, quindi per questi dati sostituisci ogni + con uno spazio prima di decodificare; in quel formato un vero segno più viene scritto come %2B e viene comunque decodificato correttamente. L’errore compare quando un % non è seguito da due cifre esadecimali, come in 50% di sconto, o quando i byte codificati non sono UTF-8 valido, come in %E2%82.

Quali token può leggere «Decodifica JWT»?

I token nella forma compatta in tre parti header.payload.signature usata dai JWT firmati (JWS), compresi i token non firmati con la parte della firma vuota. La firma non viene verificata, quindi un token decodificato non dimostra di essere autentico. I token cifrati (JWE) hanno cinque parti e il loro payload non si può leggere senza la chiave, quindi danno un errore di formato. Un’intestazione o un payload che non si decodifica da Base64 in JSON, oppure un payload che è un valore semplice, come una stringa o un numero, invece di un oggetto JSON, produce un messaggio «Errore di analisi del JWT». Gli interi maggiori di 9.007.199.254.740.991 nell’intestazione o nel payload possono essere arrotondati quando il browser analizza il JSON, quindi gli ID numerici lunghi possono comparire con le ultime cifre diverse.

Come vengono mostrati i tempi exp, nbf e iat, e quando un token è segnato come scaduto?

I valori vengono letti come tempo Unix in secondi, come li definisce lo standard JWT (RFC 7519), e mostrati in UTC e nella tua ora locale. «SCADUTO» e «Non ancora valido» confrontano exp e nbf con l’orologio del tuo dispositivo nel momento in cui fai clic su «Decodifica JWT», senza alcuna tolleranza per le differenze tra orologi, quindi un orologio sbagliato dà uno stato sbagliato. I server possono concedere un piccolo margine, spesso non più di qualche minuto, quindi in prossimità dell’ora di exp o nbf un server può decidere diversamente dallo stato mostrato qui. Un tempo scritto come stringa, come "1700000000", viene segnalato come timestamp Unix numerico non valido.