Il nostro strumento di codifica e decodifica URL converte URL e testo nel formato codificato in percentuale e viceversa in tempo reale. Codifica caratteri speciali, parametri di query, segmenti di percorso e testo Unicode per un uso sicuro negli URL. Decodifica le stringhe codificate in percentuale riportandole a testo leggibile. Supporta la codifica standard RFC 3986, la codifica dei componenti e la codifica URL completa con supporto UTF-8. Tutta l'elaborazione avviene lato client: i tuoi dati non lasciano mai il tuo browser.
Seleziona Codifica per convertire il testo in formato URL, oppure Decodifica per riconvertire il testo codificato in percentuale.
Scegli Componente (per i valori di query), URI (per gli URL completi) o Dati modulo (+ per gli spazi).
Digita o incolla il tuo testo (da codificare) o l'URL codificato (da decodificare).
Il risultato appare all'istante. Fai clic su Copia per copiarlo negli appunti.
La codifica URL (codifica percentuale) sostituisce i caratteri non sicuri o riservati con un simbolo di percentuale (%) seguito da due cifre esadecimali che rappresentano il valore in byte del carattere. Ad esempio, uno spazio diventa %20 e '&' diventa %26. I caratteri UTF-8 utilizzano più byte codificati in percentuale (ad es. '€' → %E2%82%AC). I caratteri non riservati (lettere, cifre, -, _, ., ~) non vengono mai codificati.
URL Encoding = replace unsafe characters → %HH (hex byte value)
Usa encodeURIComponent per i valori dei parametri di query: codifica tutto eccetto A-Z a-z 0-9 - _ . ~
Usa encodeURI per gli URL completi: conserva :, /, ?, #, &, = e altri caratteri di struttura dell'URL
Gli spazi possono essere codificati come %20 (standard) o + (dati di modulo / application/x-www-form-urlencoded)
Codifica sempre l'input dell'utente prima di inserirlo negli URL per prevenire attacchi di injection
I caratteri UTF-8 come le emoji vengono codificati come byte %HH multipli (ad es., 😀 → %F0%9F%98%80)
La doppia codifica si verifica quando codifichi una stringa già codificata: se non sei sicuro, decodifica prima
Lo standard RFC 3986 stabilisce che i caratteri non riservati (A-Z a-z 0-9 - _ . ~) non vengono mai codificati
Il nostro strumento online gratuito per codificare e decodificare URL converte all'istante il testo nel formato codificato in percentuale e viceversa. Codifica parametri di query, segmenti di percorso e caratteri speciali per un uso sicuro negli URL. Decodifica le stringhe percent-encoded riportandole a testo leggibile. Supporta UTF-8 e tutti i caratteri Unicode.
Converti all'istante qualsiasi testo in una codifica percentuale sicura per URL. Il nostro strumento gestisce spazi, caratteri speciali, Unicode ed emoji.
Scegli tra:
Decodifica qualsiasi URL codificato in percentuale riportandolo a testo leggibile. Incolla URL codificati, stringhe di query o singoli parametri e visualizza immediatamente il testo originale.
Gestisce:
La codifica URL funziona sostituendo qualsiasi carattere non sicuro o riservato in un URL con un simbolo di percentuale seguito da due cifre esadecimali che rappresentano il valore in byte di quel carattere, uno schema formalmente definito nella RFC 3986 dall'IETF.
Uno spazio diventa %20, una e commerciale (&) diventa %26 e una barra (/) diventa %2F. I caratteri non ASCII vengono prima convertiti nella loro sequenza di byte UTF-8, poi ogni byte viene codificato in percentuale, quindi la lettera 'é' diventa %C3%A9.
Secondo i MDN Web Docs, i browser applicano questa operazione automaticamente tramite funzioni come encodeURIComponent. Solo i caratteri non riservati (A-Z, a-z, 0-9, trattino, trattino basso, punto, tilde) rimangono inalterati.
encodeURI codifica un URL completo mantenendo i caratteri strutturali riservati, mentre encodeURIComponent codifica un singolo componente e converte anche tali caratteri strutturali.
Come documentato da MDN Web Docs, encodeURI lascia intatti :, /, ?, #, & e = in modo che l'intero indirizzo rimanga funzionale, rendendolo adatto per URL completi. encodeURIComponent converte tutto tranne il set non riservato della RFC 3986, rivelandosi la scelta corretta per i valori dei parametri di query, i segmenti di percorso o il testo dei frammenti che potrebbero contenere caratteri riservati.
Usare encodeURI dove serve encodeURIComponent è un errore comune: una & non codificata all'interno di un valore verrà interpretata erroneamente come separatore di parametri, corrompendo la richiesta senza generare errori evidenti.
La norma RFC 3986 divide i caratteri URL in set non riservati e riservati, e questa distinzione determina ciò che viene codificato in percentuale.
Secondo la specifica IETF, i caratteri riservati possono apparire non codificati quando svolgono il loro ruolo di delimitatori, ma devono essere codificati in percentuale quando vengono usati letteralmente all'interno di un componente. Tutto ciò che si trova al di fuori di entrambi i set, compresi gli spazi e i caratteri Unicode, deve essere sempre codificato.
Gli URL usano %20 per gli spazi perché la specifica RFC 3986 non consente l'uso letterale dello spazio in un URI, per cui viene codificato con la percentuale (percent-encoding) in base al suo valore di byte ASCII, ovvero l'esadecimale 20.
Esiste una seconda convenzione: nei dati application/x-www-form-urlencoded (il formato usato per l'invio di moduli HTML e per molte stringhe di query), lo spazio viene codificato come segno più (+) anziché %20, come specificato dal WHATWG URL Standard e dalle specifiche sui moduli W3C.
Per questo motivo i decodificatori devono conoscere il contesto. %20 è universalmente sicuro nel percorso (path), nella query e nel frammento, mentre + significa spazio solo all'interno dei dati di query con codifica da modulo, ed è un segno più letterale in qualsiasi altra posizione.
La codifica URL gestisce Unicode convertendo prima ogni carattere nella sua sequenza di byte UTF-8 e poi applicando il percent-encoding a ciascun singolo byte. Il Consorzio Unicode definisce i code point, mentre UTF-8 (specificato nella RFC 3629) li mappa da uno a quattro byte.
Ad esempio:
MDN Web Docs rileva che la funzione encodeURIComponent di JavaScript opera su UTF-8 per impostazione predefinita. I decodificatori invertono questo processo raccogliendo i byte codificati e reinterpretandoli come uno stream UTF-8 per recuperare il testo originale.
La doppia codifica (double encoding) si verifica quando una stringa già codificata con percent-encoding viene codificata una seconda volta, trasformando ogni % in %25, cosicché %20 diventa %2520 e il valore non può più essere letto correttamente.
Questa è una causa frequente di link interrotti e, secondo l'OWASP, un problema di sicurezza poiché gli attaccanti usano la doppia codifica per far passare input malevoli attraverso filtri che eseguono la decodifica una sola volta.
Per evitarla, codifica un valore esattamente una volta nel punto in cui entra nell'URL e non ricodificare mai dati provenienti da un'altra fonte già codificata. Se non sai con certezza se una stringa sia già codificata, decodificala prima: se l'output cambia e risulta leggibile, significa che era codificata e non dovresti codificarla di nuovo.
La codifica URL non è sicura e non garantisce alcuna riservatezza; si tratta di una trasformazione reversibile pensata per la sicurezza del trasporto, non di una crittografia. Chiunque può decodificare all'istante una stringa in percent-encoding, quindi i dati sensibili inseriti in un URL rimangono completamente leggibili e, come avverte l'OWASP, risultano visibili anche nella cronologia del browser, nei log dei server e negli header Referer.
La codifica serve solo a garantire che i caratteri speciali non compromettano la sintassi dell'URL. La crittografia, al contrario, utilizza una chiave e algoritmi come AES (standardizzato dal NIST) per rendere i dati illeggibili senza tale chiave.
L'uso corretto della codifica in ottica di sicurezza consiste nell'associarla al corretto escaping dell'output per prevenire attacchi di injection; non considerarla mai un modo per nascondere o proteggere le informazioni.
Per codificare correttamente una stringa di query, applica encodeURIComponent a ciascuna chiave e valore del parametro separatamente prima di unirli con & ed =, anziché codificare l'intera stringa assemblata in una volta sola.
In questo modo si garantisce che i caratteri riservati all'interno di un valore, come & o = nell'input dell'utente, vengano convertiti in %26 e %3D affinché non possano essere scambiati per delimitatori, seguendo le regole di application/x-www-form-urlencoded descritte dallo standard WHATWG URL. Ad esempio, il valore 'hello world&x=1' deve diventare 'hello%20world%26x%3D1'.
Secondo MDN Web Docs, l'API URLSearchParams automatizza questo processo in modo sicuro. Codifica sempre i dati forniti dall'utente prima di inserirli in una stringa di query per prevenire attacchi di parameter injection e richieste malformate.
L'errore più comune nella codifica degli URL è la scelta della funzione sbagliata: l'uso di encodeURI su un valore di query lascia non convertiti &, = e ?, consentendo all'input dell'utente di alterare la struttura dell'URL.
Altri errori frequenti, diversi dei quali segnalati da OWASP e MDN Web Docs, includono:
Gli sviluppatori gestiscono in modo errato anche UTF-8 decodificando i byte come Latin-1, il che genera mojibake per i testi accentati e non latini. Infine, non affidarti mai alla codifica per la sicurezza: la mancata esecuzione dell'escaping dell'output per il contesto di destinazione lascia aperte vulnerabilità di injection nonostante un percent-encoding valido.
Data sourced from trusted institutions
All formulas verified against official standards.