Lunghezza massima di un URL: il limite reale in caratteri

Non esiste una lunghezza massima di un URL. RFC 3986, lo standard che definisce la sintassi degli URI, non ne stabilisce una - descrive quali caratteri sono legali e come si costruisce un URL, e si ferma lì. Quello che incontri davvero è una catena di limiti separati e senza relazione tra loro: la barra degli indirizzi del tuo browser, il server web dall'altra parte, il proxy che sta in mezzo, il client email in cui qualcuno apre il tuo link, o il QR code che stai per stampare. Ognuno impone il proprio limite, e la vera lunghezza massima di un URL è quella del limite più basso. Spedisci un URL di 3.000 caratteri e potrebbe visualizzarsi correttamente in Chrome, venire rifiutato da un server con le impostazioni di default, e arrivare in Outlook diviso su quattro righe. Niente di tutto questo è un bug. È la conseguenza pratica di uno standard deliberatamente silenzioso sulla questione.

Ne seguono quattro cose: cosa dice e cosa non dice lo standard, da dove viene il famoso numero di 2.083 caratteri e perché continua a comparire nelle checklist anni dopo aver smesso di contare, i limiti che mordono davvero una volta che un link lascia il browser, e cosa fare con un URL che è cresciuto troppo. Per cosa fa uno shortener con tutto questo sulla rete, vedi come funzionano gli URL shortener.

Cosa dice davvero RFC 3986 sulla lunghezza di un URL

RFC 3986 definisce la sintassi generica degli URI - schema, autorità, percorso, query, frammento - e tace su quanto possa essere lunga ciascuna parte. Non tace per omissione; tace per scelta di design. La grammatica nella sezione 3 costruisce un URI a partire da un piccolo insieme di regole di produzione, e niente in quelle regole limita quante volte una regola possa ripetersi. Un segmento di percorso può essere lungo un carattere o centomila, per quanto riguarda la sintassi. Gli URL lunghi sono URL perfettamente legali.

L'unico limite che l'RFC impone davvero è indiretto: il componente di autorità di un URL include un hostname, e il DNS limita un hostname completamente qualificato ben al di sotto di ciò che la grammatica dell'URI permette - la documentazione tecnica di Chromium fissa quel limite a 253 caratteri totali, 63 per etichetta. Percorso, query string e frammento non portano alcun vincolo del genere da nessuna parte nello standard.

Questa è tutta la storia dal lato dello standard. Il limite di caratteri di un URL che incontri davvero in pratica viene dal software che legge l'URL, mai dal formato dell'URL in sé.

Da dove viene 2.083, e cosa fanno oggi i browser

Se hai visto da qualche parte una linea guida sulla lunghezza degli URL, citava 2.083 caratteri. Quel numero è reale, ma appartiene a un browser, un'epoca e un percorso di codice. La libreria di rete WinINET di Internet Explorer definiva INTERNET_MAX_URL_LENGTH come 2083 caratteri, e l'articolo tecnico di Microsoft sul limite nota che la barra degli indirizzi stessa era limitata a un carattere in meno, 2047. Quel limite ha governato una fetta enorme del traffico web per oltre un decennio, quindi è diventato il numero a cui tutti progettavano, e l'abitudine di citarlo è sopravvissuta al browser che descrive.

I browser moderni non funzionano così. La documentazione di Chrome indica un limite interno di 2 megabyte, imposto per evitare problemi di comunicazione tra processi piuttosto che per proteggere un campo dell'interfaccia, con una costante molto più piccola, circa 32 kilobyte su desktop, che limita ciò che l'omnibox mostra effettivamente. Firefox e Safari sono altrettanto generosi - nessuno dei due si blocca su un URL anche lontanamente vicino alla lunghezza che probabilmente costruiresti a mano. Non ho mai debuggato un problema reale in produzione causato da un browser moderno che rifiutava un URL lungo. Ogni bug da URL lungo che ho tracciato è iniziato a valle del browser.

I limiti reali che mordono davvero

Metti in fila dove viaggia davvero un URL e uno schema emerge in fretta: il limite più stretto è raramente quello nel browser.

• La riga di richiesta del server legge l'URL come parte della prima riga di una richiesta HTTP, e quella riga ha un proprio buffer. Superalo e il server non analizza mai la tua route - rifiuta la connessione prima ancora che il codice della tua applicazione venga eseguito.
• I client email gestiscono il superamento in modi diversi. Outlook va a capo con un lungo URL in testo semplice su più righe invece di troncarlo, il che è brutto ma resta cliccabile; alcuni client webmail e gateway di inoltro sono meno indulgenti e tagliano il link di netto.
• Un link dentro un messaggio di testo compete con il corpo del messaggio per lo stesso budget di caratteri, e i link per l'SMS marketing vivono dentro un segmento di 160 caratteri - un URL lungo da solo può far passare un SMS a segmento singolo a due segmenti, che gli operatori fatturano e filtrano in modo diverso.
• Un QR code non tronca un URL lungo; diventa semplicemente più denso. Quanto deve essere grande un QR code dipende direttamente da quanto gli chiedi di codificare, e un URL carico di parametri di tracciamento può far salire un codice di una versione o due, riducendo la distanza da cui si scansionerà ancora.
• Le funzioni di collegamento ipertestuale dei fogli di calcolo impongono un proprio limite rigido di caratteri sull'argomento del link, ben al di sotto di un tipico URL taggato, e un link che lo supera fallisce silenziosamente - la cella si mostra bene, ma il link in sé non funziona.
• Le piattaforme pubblicitarie limitano il campo dell'URL di destinazione a una lunghezza fissa di loro scelta, una regola della piattaforma più che tecnica, e chi gestisce la campagna se ne accorge solo quando il pulsante di salvataggio rifiuta ciò che un browser aprirebbe senza problemi.

Nessuno di questi limiti comunica con gli altri. Un URL può superare la riga di richiesta del tuo server e comunque morire in un foglio di calcolo tre reparti più avanti.

Limiti della riga di richiesta di server e proxy

Il caso del server merita uno sguardo a parte, perché è quello che produce un vero codice di errore invece di un glitch cosmetico. 414 Request-URI Too Long è la risposta che un server invia quando rifiuta di elaborare una richiesta perché l'URI è più lungo di quanto sia disposto a interpretare - un limite di dimensione dell'URL imposto un salto alla volta, da qualunque software stia leggendo la riga di richiesta in quel momento.

Ogni server e proxy della catena impone la propria versione di questo limite. La direttiva LimitRequestLine di Apache ha come default 8.190 byte per l'intera riga di richiesta, che include il metodo e la versione del protocollo, non solo l'URL in sé. nginx legge gli header della richiesta in un buffer fisso controllato da large_client_header_buffers, 8 kilobyte di default, e una riga di richiesta che non ci sta riceve un 414 prima ancora che la tua route venga trovata. I load balancer e le CDN davanti all'uno o all'altro applicano spesso un terzo limite separato, quindi un URL può superare l'impostazione del tuo server di origine e comunque venire rifiutato un salto prima.

Se non controlli ogni salto, e oltre una certa dimensione aziendale nessuno lo fa, la mossa sicura è progettare per il default comune più stretto piuttosto che per il più generoso che hai trovato in un file di configurazione.

Costruire da solo il livello di redirect invece di scrivere a mano il parsing delle richieste è la soluzione noiosa qui. L'API di Elido accetta una destinazione di qualsiasi lunghezza ragionevole e restituisce un link breve che non cambia mai dimensione, così il limite della riga di richiesta di un server diventa qualcosa che configuri una volta sola all'edge invece di qualcosa che ogni integrazione deve gestire per conto proprio.

Come misurare la lunghezza reale di un URL prima di pubblicarlo

Il conteggio dei caratteri è tutta la misura, e vale la pena controllarlo prima che un URL entri in una campagna piuttosto che dopo che arriva un report di bounce.

printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c

Questo ti dà la lunghezza in byte dell'URL esattamente come scritto. Due cose lo complicano. Primo, i caratteri percent-encoded costano più di quanto sembrino: una lettera accentata o un'emoji dentro il valore di una query possono espandersi a sei caratteri o più una volta codificati, quindi misura l'URL dopo la codifica, non prima. Secondo, i parametri UTM sono di solito la parte di un URL che cresce più in fretta - una manciata di tag di campagna, sorgente, mezzo e contenuto può aggiungere diverse centinaia di caratteri a quello che era partito come un percorso breve, e sono il primo posto dove guardare quando un URL è cresciuto troppo in silenzio.

Se un link che prima funzionava improvvisamente smette di farlo, esegui la stessa traccia che useresti per qualsiasi link morto: link breve che non funziona illustra come controllare direttamente la destinazione, che è esattamente il modo in cui scoprirai un URL cresciuto oltre il limite di un server un parametro di tracciamento alla volta.

Cosa fare quando un URL è troppo lungo

Ci sono due correzioni che funzionano davvero, e sono le stesse due indipendentemente dal limite che hai fatto scattare.

La prima è abbreviare l'URL. Un link breve è un puntatore a lunghezza fissa - lo slug resta della stessa lunghezza indipendentemente da quanto crescano la destinazione o i suoi parametri di tracciamento, perché tutto questo vive lato server e viene recuperato a ogni clic invece di essere trasportato dentro il link stesso. Questo risolve in una sola mossa il problema della densità del QR code, il problema dei segmenti SMS e il problema dei fogli di calcolo, dato che tutti e tre si preoccupano del numero di caratteri del link, non della lunghezza di dove alla fine punta.

La seconda è spostare completamente lo stato fuori dalla query string. Se quello che rende lungo il tuo URL sono dati di sessione, un blob del contenuto del carrello o una lunga lista di filtri piuttosto che veri parametri di tracciamento, quei dati di solito appartengono lato server dietro un ID opaco, non scritti per esteso nella barra degli indirizzi. Un URL che si legge /checkout?session=a1b2c3d4 invecchia meglio di uno che si legge /checkout?items=... con ogni SKU e quantità scritti per intero, ed elude in un colpo solo ogni limite di questo articolo, perché non resta più niente di lungo da misurare.

Entrambe le correzioni puntano nella stessa direzione: tratta la lunghezza di un URL come una decisione di design, non come l'incidente di quanti parametri si sono accumulati sopra.

Leggi la serie cornerstone

Questo articolo fa parte del cluster engineering. Per quello che succede dall'altra parte di un link breve, come funzionano gli URL shortener copre la lookup in sé, e tipi di redirect URL copre i codici di stato coinvolti una volta trovata la destinazione.

Correlati nel blog

• URL encoding spiegato: quali caratteri codificare
• Parametri UTM spiegati, con uno schema di denominazione che resiste
• Quanto deve essere grande un QR code? Regole di dimensione e distanza
• Uno shortener URL per l'SMS marketing di cui gli operatori si fidano
• Link breve che non funziona? Diagnosticalo con un comando