Skip to content

Codificatore e Decodificatore URL con Parser URL Integrato

Decodifica o codifica URL in tempo reale con parser URL integrato. Doppia modalità: encodeURI e encodeURIComponent. 100% privato, nessun dato inviato a server online.

Niente tracciamento Funziona nel browser Gratuito
Decodificato
Codificato
Revisionato per la conformità alla RFC 3986, la correttezza di encodeURI/encodeURIComponent e l'accuratezza della codifica UTF-8 — Team di Ingegneria Go Tools · Apr 7, 2026

Cos'è la Codifica URL (Percent-Encoding)?

La codifica URL, formalmente nota come percent-encoding, è un meccanismo definito nella RFC 3986 per rappresentare nei Uniform Resource Identifier (URI) caratteri che non sono permessi o che hanno un significato speciale. Converte ogni byte non sicuro in un segno di percentuale (%) seguito da due cifre esadecimali — per esempio, uno spazio diventa %20, una e-commerciale diventa %26, e il carattere cinese 中 diventa %E4%B8%AD (i suoi tre byte UTF-8, ciascuno percent-encoded).

Gli URL possono contenere solo un insieme limitato di caratteri del set ASCII. Lettere, cifre e una manciata di simboli (- _ . ~) sono considerati 'non riservati' e possono apparire così come sono. Tutti gli altri caratteri — inclusi spazi, punteggiatura e l'intero range di Unicode — devono essere codificati con percent-encoding per essere trasmessi in sicurezza in un URL. I caratteri riservati come ?, &, =, e # fungono da delimitatori strutturali nella sintassi URL, quindi devono essere codificati anche quando vengono usati come dati letterali piuttosto che come delimitatori.

Il percent-encoding è essenziale in tutto il web: i browser codificano gli invii dei form, le API richiedono parametri di query codificati, i flussi OAuth dipendono da URI di reindirizzamento codificati correttamente, e i nomi di dominio internazionalizzati si basano sulla codifica per i caratteri non ASCII. Sbagliare la codifica porta a link rotti, vulnerabilità di sicurezza (come gli attacchi open redirect) e corruzione dei dati.

Questo strumento fornisce sia le modalità encodeURI che encodeURIComponent, un parser della struttura URL integrato, conversione in tempo reale, e rilevamento della doppia codifica — tutto eseguito privatamente nel tuo browser.

La codifica URL viene spesso usata insieme ad altri strumenti di sviluppo web. Potresti aver bisogno di codificare un URL in Base64 per incorporarlo in un token JWT o in un payload API, oppure formattare dati JSON che contengono stringhe URL per ispezionarne la struttura. Per una panoramica più approfondita, a livello di byte, di come funziona il percent-encoding, leggi la nostra guida completa alla codifica URL per sviluppatori.

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

Caratteristiche Principali

Doppia Modalità di Codifica

Cambia tra encodeURI (preserva la struttura dell'URL) e encodeURIComponent (codifica tutto per i valori dei parametri) per adattarti esattamente al tuo caso d'uso.

Parser URL Integrato

Scompone automaticamente qualsiasi URL in protocollo, host, porta, percorso, parametri di query e frammento — ogni campo è modificabile e può essere ricostruito in un nuovo URL.

Conversione in Tempo Reale

Codifica e decodifica istantaneamente mentre digiti — nessun pulsante da cliccare, i risultati appaiono immediatamente nell'altra area a ogni tasto premuto.

100% Basato sul Browser

Tutta l'elaborazione avviene localmente nel tuo browser usando le API native di JavaScript. I tuoi dati non lasciano mai il tuo dispositivo — nessun upload sul server, nessun tracciamento.

Pieno Supporto UTF-8

Gestisce correttamente cinese, giapponese, coreano, arabo, emoji e qualsiasi testo Unicode tramite una corretta codifica e decodifica dei byte UTF-8.

Rilevamento Doppia Codifica

Rileva automaticamente e avvisa su problemi di doppia codifica come %2520 (un %20 percent-encoded), aiutandoti a evitare uno degli errori di codifica URL più comuni.

Esempi

Decodifica un URL Illeggibile

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

Un URL completamente codificato in percent-encoding viene decodificato nella sua forma leggibile, rivelando i parametri di query e la struttura originali

Caratteri Cinesi

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

I caratteri cinesi vengono convertiti nelle loro sequenze di byte UTF-8 e codificati con percent-encoding

Parametri di Query

https://example.com/api?name=John Doe&role=admin&lang=en&sort=date desc
https://example.com/api?name=John%20Doe&role=admin&lang=en&sort=date%20desc

Gli spazi e i caratteri speciali nei valori dei parametri di query vengono codificati con percent-encoding mantenendo intatta la struttura dell'URL

URL Completo

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

Un URL completo con credenziali, porta, percorso, parametri di query con parentesi quadre e un identificatore di frammento

URI di Reindirizzamento OAuth

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

Il valore di redirect_uri contiene a sua volta un URL completo che deve essere codificato affinché i suoi caratteri speciali non vengano interpretati come parte dell'URL esterno

Come Usare

  1. 1

    Inserisci un URL o una Stringa Codificata

    Incolla un URL nell'area decodificata per codificarlo, oppure incolla una stringa percent-encoded nell'area codificata per decodificarla. Seleziona la modalità encodeURI o encodeURIComponent in base al tuo caso d'uso.

  2. 2

    Vedi i Risultati e la Struttura Analizzata

    L'altra area si aggiorna istantaneamente mentre digiti. Il parser URL scompone l'URL in protocollo, host, porta, percorso, parametri di query e frammento — tutto modificabile.

  3. 3

    Copia o Ricostruisci

    Clicca Copia per copiare il risultato codificato o decodificato. Modifica i singoli componenti dell'URL e clicca Ricostruisci per costruire un nuovo URL dalle parti modificate.

Errori Comuni

Doppia Codifica (%2520 invece di %20)

La doppia codifica si verifica quando un URL già codificato viene codificato di nuovo. Il % in %20 viene codificato come %25, trasformando %20 in %2520. Questo rompe l'URL perché il server vede una stringa letterale %20 invece di uno spazio.

✗ Errato
https://example.com/path%2520with%2520spaces
✓ Corretto
https://example.com/path%20with%20spaces

Spazio Codificato come + nei Segmenti di Percorso

Il carattere + rappresenta uno spazio solo nel formato application/x-www-form-urlencoded (query string dei form HTML). Nei segmenti di percorso URL, + viene interpretato come un segno più letterale, non come uno spazio. Usa sempre %20 per gli spazi nei segmenti di percorso.

✗ Errato
https://example.com/my+file+name.pdf
✓ Corretto
https://example.com/my%20file%20name.pdf

Usare encodeURI sui Valori dei Parametri di Query

encodeURI() non codifica &, =, o altri caratteri riservati, quindi usarlo su un valore di parametro che contiene questi caratteri corrompe la struttura della query string.

✗ Errato
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ Corretto
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

Assumere una Codifica Diversa da UTF-8

Alcuni sistemi legacy usano codifiche come Latin-1 o Shift-JIS per i parametri URL. Gli standard moderni richiedono UTF-8. Decodificare un parametro codificato in Shift-JIS con un decodificatore UTF-8 produce testo corrotto.

✗ Errato
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ Corretto
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

Codificare Percorsi Relativi Senza Contesto

Codificare un percorso relativo come ../images/photo.jpg con encodeURIComponent trasforma le barre e i punti in sequenze percent-encoded, rompendo la struttura del percorso. Usa encodeURI() o codifica solo i singoli segmenti del percorso.

✗ Errato
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ Corretto
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

Casi d'Uso Comuni

Debug di URL Illeggibili
Decodifica URL percent-encoded dai log dei server, dai messaggi di errore o dagli strumenti per sviluppatori del browser per leggere il testo originale leggibile.
Sviluppo API
Codifica i valori dei parametri di query per le chiamate API REST, assicurandoti che caratteri speciali come &, =, e gli spazi non rompano l'URL della richiesta.
Configurazione del Flusso OAuth
Codifica correttamente redirect_uri e altri parametri URL negli URL di autorizzazione OAuth per prevenire fallimenti di autenticazione.
URL Internazionalizzati
Codifica e decodifica URL contenenti caratteri cinesi, giapponesi, coreani, arabi o altri caratteri non ASCII per applicazioni web internazionalizzate.
Analisi di Link di Marketing
Decodifica URL di tracciamento da campagne email e piattaforme pubblicitarie per comprendere i parametri UTM incorporati e le catene di reindirizzamento.
Ispezione della Struttura URL
Analizza URL complessi nelle loro parti componenti — protocollo, host, porta, percorso, parametri di query e frammento — per analisi e modifica.

Dettagli Tecnici

Caratteri Riservati e Non Riservati della RFC 3986
La RFC 3986 definisce i caratteri non riservati (A-Z, a-z, 0-9, -, ., _, ~) che non hanno mai bisogno di codifica, e i caratteri riservati (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =) che fungono da delimitatori URI e devono essere codificati con percent-encoding quando usati come dati.
Flusso di Codifica dei Byte UTF-8
I caratteri non ASCII vengono prima convertiti nel loro code point Unicode, poi codificati come byte UTF-8 (1-4 byte a seconda dell'intervallo del code point), e infine ogni byte viene codificato con percent-encoding come %XX. Per esempio: é (U+00E9) → byte UTF-8 C3 A9 → %C3%A9. L'emoji 🎉 (U+1F389) → byte UTF-8 F0 9F 8E 89 → %F0%9F%8E%89.
Terminologia URL vs URI
Un URI (Uniform Resource Identifier) è il termine generale per qualsiasi stringa identificatrice. Un URL (Uniform Resource Locator) è un URI che specifica anche il meccanismo di accesso (come https://). Le regole di codifica nella RFC 3986 si applicano a tutti gli URI. L'API di JavaScript usa la terminologia URI (encodeURI, decodeURI), mentre l'uso quotidiano preferisce URL.

Migliori Pratiche

Usa la Modalità Giusta per il Compito
Usa encodeURIComponent() per le singole chiavi e i valori dei parametri di query. Usa encodeURI() solo quando hai un URL completo e vuoi codificare i caratteri non sicuri senza romperne la struttura. Non usare mai encodeURI() su valori di parametri che potrebbero contenere &, =, o altri caratteri riservati.
Evita la Doppia Codifica
Prima di codificare una stringa, controlla se è già codificata. Cerca sequenze % esistenti. Codificare una stringa già codificata trasforma %20 in %2520, %3D in %253D, e così via. Se non sei sicuro, decodifica prima, poi codifica una sola volta.
Decodifica sul Lato Server
La maggior parte dei framework web decodifica automaticamente i parametri URL prima che il codice della tua applicazione li veda. Evita di decodificare manualmente parametri che il tuo framework ha già decodificato — questo può causare problemi se il valore originale conteneva sequenze percent letterali.
Codifica i Valori per OAuth e API Signing
Le stringhe base delle firme OAuth 1.0 e molti algoritmi di firma API richiedono un percent-encoding rigoroso secondo la RFC 3986. Usa encodeURIComponent() e poi sostituisci eventuali caratteri rimanenti che non codifica (come !, ', (, ), *) con i loro equivalenti percent-encoded se la specifica lo richiede.

Domande Frequenti

Cos'è la codifica URL e perché è necessaria?
La codifica URL (percent-encoding) converte i caratteri non sicuri in sequenze esadecimali %XX così possono essere inseriti in modo sicuro negli URL. Caratteri come spazi, e-commerciali e testo non ASCII devono essere codificati perché altrimenti romperebbero la struttura dell'URL o verrebbero interpretati erroneamente da browser e server. Definito nella RFC 3986, questo meccanismo funziona perché gli URL possono contenere solo un insieme limitato di caratteri US-ASCII — lettere (A-Z, a-z), cifre (0-9) e pochi simboli come trattini, underscore, punti e tilde. Qualsiasi carattere fuori da questo insieme sicuro viene codificato come un segno di percentuale (%) seguito da due cifre esadecimali che rappresentano il valore in byte del carattere. Per esempio, uno spazio diventa %20, una barra diventa %2F e una e-commerciale diventa %26. Caratteri come &, =, ?, e # hanno un significato strutturale speciale negli URL — delimitano parametri di query, frammenti e altri componenti. Senza la codifica, una & letterale nel valore di un parametro verrebbe interpretata erroneamente come separatore di parametri, rompendo completamente la struttura dell'URL.
Qual è la differenza tra encodeURI e encodeURIComponent?
encodeURI() codifica un URL completo preservando i caratteri strutturali come :, /, ?, e #. encodeURIComponent() codifica tutto tranne lettere, cifre, e - _ . ~, rendendola la scelta corretta per codificare singoli valori di parametri di query. Usa encodeURIComponent() per chiavi e valori dei parametri, e encodeURI() solo per URL completi. Per esempio, encodeURI('https://example.com/path name') produce 'https://example.com/path%20name', preservando :// e /. encodeURIComponent() è molto più aggressivo — codifica :, /, ?, #, &, e =. Se usassi encodeURI() su un valore di parametro contenente una e-commerciale, la & passerebbe non codificata e verrebbe interpretata erroneamente come separatore di parametri. encodeURIComponent() la codificherebbe correttamente come %26. Confondere questi due è una delle cause più comuni di bug legati agli URL nelle applicazioni web.
La codifica URL è uguale alla codifica HTML?
No. La codifica URL converte i caratteri in sequenze esadecimali %XX per gli URL (RFC 3986), mentre la codifica HTML converte i caratteri in entità come & e < per i documenti HTML. Servono a scopi completamente diversi e non devono mai essere scambiate. La codifica URL serve al trasporto dei dati negli URL — uno spazio diventa %20. La codifica HTML serve a mostrare contenuto in HTML in modo sicuro — una e-commerciale diventa &. Un errore comune è applicare la codifica HTML ai parametri URL o viceversa. Per esempio, codificare uno spazio come   in un URL non funzionerebbe — deve essere %20 o +. Allo stesso modo, usare %3C nel testo HTML invece di < non otterrebbe l'escape desiderato.
Perché il mio URL si rompe quando lo uso in un comando curl?
La shell interpreta i caratteri URL speciali prima che curl li veda: & esegue comandi in background, ? attiva il globbing, e # avvia un commento. Risolvi racchiudendo l'URL tra apici singoli: curl 'https://example.com/api?key=value&page=2#section'. Gli apici singoli impediscono alla shell di interpretare qualsiasi carattere speciale. La e-commerciale (&) è il colpevole più comune — dice alla shell di eseguire il comando precedente in background, spezzando il tuo URL alla prima & e scartando tutto ciò che segue. In alternativa, puoi fare l'escape dei singoli caratteri con backslash, ma racchiudere l'intero URL tra virgolette è più semplice e meno soggetto a errori. Se il tuo URL contiene anche apici singoli, usa invece le doppie virgolette e fai l'escape di eventuali simboli del dollaro o backtick incorporati.
Perché i caratteri cinesi diventano stringhe come %E4%B8%AD negli URL?
I caratteri cinesi vengono prima convertiti in byte UTF-8, poi ogni byte viene codificato con percent-encoding come %XX. Il carattere 中 (U+4E2D) diventa tre byte UTF-8 (E4, B8, AD), producendo %E4%B8%AD — ecco perché un carattere cinese si espande in 9 caratteri in un URL. Questo processo a tre passi — carattere a code point Unicode, code point a byte UTF-8, byte a esadecimale percent-encoded — si applica a tutti i caratteri non ASCII. Le emoji richiedono spesso 4 byte UTF-8 e quindi si espandono a 12 caratteri quando vengono codificate. Quando l'URL viene decodificato, accade l'inverso: i valori esadecimali vengono riconvertiti in byte, i byte vengono interpretati come UTF-8 e i caratteri originali vengono ripristinati.
Devo codificare il parametro redirect_uri di OAuth?
Sì, codificalo sempre con encodeURIComponent(). redirect_uri è un URL completo incorporato come valore di parametro di query, quindi i suoi caratteri speciali (?, &, =) devono essere codificati per evitare che vengano interpretati come parte della struttura dell'URL esterno. Per esempio, redirect_uri=https://myapp.com/callback?code=abc&state=xyz senza codifica farebbe sì che il server di autorizzazione veda redirect_uri solo come https://myapp.com/callback?code=abc, mentre state=xyz verrebbe analizzato come un parametro separato dell'URL esterno. La versione codificata correttamente è redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz.
Qual è la differenza tra querystring di Node.js e URLSearchParams?
Usa URLSearchParams per i nuovi progetti — è lo standard WHATWG, corrisponde al comportamento del browser e funziona in modo identico in Node.js e nei browser. Il modulo querystring è legacy e non viene più sviluppato attivamente. Differenze chiave: URLSearchParams codifica gli spazi come + (standard di codifica dei form), gestisce le chiavi ripetute tramite getAll(), e fornisce un'interfaccia iterabile con i metodi entries(), keys(), e values(). Il modulo querystring codifica gli spazi come %20 e ha alcune stranezze nella gestione degli array (key=1&key=2 diventa { key: ['1', '2'] }). URLSearchParams è conforme agli standard ed è raccomandato dalla documentazione stessa di Node.js.
Come codifico un URL in Python, JavaScript e Java?
JavaScript: encodeURIComponent('hello world') produce 'hello%20world'. Python: urllib.parse.quote('hello world') produce 'hello%20world'. Java: URLEncoder.encode('hello world', StandardCharsets.UTF_8) produce 'hello+world' (sostituisci + con %20 per la RFC 3986). In JavaScript, usa encodeURIComponent() per i valori dei parametri ed encodeURI() per gli URL completi. In Python 3, usa urllib.parse.quote() per i segmenti di percorso e urllib.parse.urlencode() per i parametri di query — urlencode({'q': 'hello world'}) produce 'q=hello+world'. In Java, nota che URLEncoder usa la codifica dei form (spazi come +). Per costruire URI completi, usa java.net.URI o la classe URIBuilder di Apache HttpClient.
Quali caratteri non vengono codificati dalla codifica URL?
La RFC 3986 definisce 66 caratteri non riservati che non hanno mai bisogno di codifica: A-Z, a-z, 0-9, trattino (-), punto (.), underscore (_), e tilde (~). Questi possono apparire letteralmente in qualsiasi parte di un URL. I caratteri riservati — :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ;, e = — sono permessi nei loro ruoli strutturali (come ? per le query string) ma devono essere codificati con percent-encoding quando usati come dati letterali. In JavaScript, encodeURIComponent() codifica tutto tranne A-Z a-z 0-9 - _ . ~ e ! ' ( ) *, mentre encodeURI() preserva inoltre i caratteri riservati che fungono da delimitatori URL.
Qual è la differenza tra + e %20 per codificare gli spazi?
Entrambi rappresentano uno spazio, ma %20 è la scelta universalmente sicura. La convenzione + viene dalla codifica dei form HTML (application/x-www-form-urlencoded) e funziona solo nelle query string. Nei segmenti di percorso URL, + è un segno più letterale, non uno spazio. In caso di dubbio, usa %20. La codifica + ha origine dalle specifiche HTML — quando i browser inviano i form, gli spazi diventano + e il carattere + stesso diventa %2B. La codifica %20 viene dalla RFC 3986 (sintassi URI), dove ogni carattere non riservato viene codificato come segno di percentuale seguito da due cifre esadecimali. %20 funziona in tutte le parti di un URL: percorso, query, e frammento.
Come gestisce la codifica URL le emoji?
Una singola emoji si espande tipicamente a 12 caratteri in un URL. Le emoji vengono convertite in byte UTF-8 (di solito 4 byte), poi ogni byte viene codificato con percent-encoding come %XX. Per esempio, 🚀 (U+1F680) diventa %F0%9F%9A%80. La maggior parte delle emoji usa code point nell'intervallo U+1F000 a U+1FFFF o superiore, che richiedono 4 byte in UTF-8. Alcune emoji con modificatori di tonalità della pelle o sequenze ZWJ consistono in più code point e possono espandersi a oltre 30 caratteri quando codificate. Nonostante questa espansione, la codifica è completamente reversibile — decodificando %F0%9F%9A%80 si ottiene correttamente 🚀.
La codifica URL può essere usata per cifratura o sicurezza?
No. La codifica URL non è cifratura e non offre alcuna sicurezza. È una trasformazione completamente reversibile e deterministica — chiunque può decodificare istantaneamente una stringa percent-encoded senza alcuna chiave o segreto. Esiste unicamente per fare l'escape dei caratteri speciali e permettere il trasporto sicuro negli URL. Trattare la codifica URL come offuscamento o sicurezza è un'idea sbagliata pericolosa. Dati sensibili come password, token o informazioni personali devono essere protetti da HTTPS (cifratura TLS dell'intera richiesta), non dalla codifica URL. Inoltre, gli URL appaiono spesso nei log dei server, nella cronologia del browser e negli header referrer, quindi i dati sensibili dovrebbero generalmente essere inviati nei body delle richieste piuttosto che negli URL.
Qual è la lunghezza massima di un URL?
Non c'è un massimo ufficiale, ma mantieni gli URL sotto i 2.000 caratteri per la massima compatibilità. La maggior parte dei browser supporta circa 2.048 caratteri, Apache di default 8.190 byte, e Nginx 8.192 byte. Per dati più grandi, usa invece richieste POST. Le specifiche HTTP (RFC 7230) non definiscono una lunghezza massima dell'URL, ma esistono limiti pratici a ogni livello. Chrome e Firefox possono gestire URL che superano i 100.000 caratteri, mentre IIS limita le query string a 16.384 byte. CDN e proxy possono avere limiti ancora più severi. Quando la codifica URL espande i caratteri — specialmente testo non ASCII — un URL apparentemente breve può rapidamente avvicinarsi a questi limiti.
Qual è la differenza tra un URL e un URI?
Un URI (Uniform Resource Identifier) è qualsiasi stringa che identifica una risorsa. Un URL (Uniform Resource Locator) è un URI che specifica anche come accedervi tramite un protocollo come https://. Tutti gli URL sono URI, ma non tutti gli URI sono URL — per esempio, un URN come urn:isbn:0451450523 identifica un libro tramite ISBN ma non ti dice dove trovarlo. Nello sviluppo web quotidiano, i termini URL e URI vengono spesso usati in modo intercambiabile. Le regole di codifica definite nella RFC 3986 si applicano a entrambi. Le funzioni di JavaScript si chiamano encodeURI/decodeURI, riflettendo la terminologia URI più ampia, anche se la maggior parte degli sviluppatori lavora esclusivamente con gli URL.

Strumenti correlati

Vedi tutti gli strumenti →