Longueur maximale d'une URL : la vraie limite de caractères

Il n'existe aucune longueur maximale d'URL. La RFC 3986, la norme qui définit la syntaxe des URI, n'en fixe aucune - elle décrit quels caractères sont légaux et comment une URL est assemblée, et s'arrête là. Ce que vous rencontrez réellement, c'est une chaîne de limites distinctes et indépendantes les unes des autres : la barre d'adresse de votre navigateur, le serveur web de l'autre côté, le proxy posté entre les deux, le client de messagerie dans lequel quelqu'un ouvre votre lien, ou le code QR que vous êtes sur le point d'imprimer. Chacun impose son propre plafond, et la longueur maximale réelle d'une URL est celle du plafond le plus bas. Envoyez une URL de 3 000 caractères et elle pourra s'afficher sans problème dans Chrome, être rejetée par un serveur aux réglages par défaut, et arriver dans Outlook repliée sur quatre lignes. Rien de tout cela n'est un bug. C'est la conséquence pratique d'une norme délibérément silencieuse sur la question.

Quatre choses en découlent : ce que la norme dit et ne dit pas, d'où vient le fameux chiffre de 2 083 caractères et pourquoi il continue d'apparaître dans les listes de vérification des années après avoir cessé de compter, les limites qui mordent réellement une fois qu'un lien quitte le navigateur, et que faire d'une URL devenue trop longue. Pour ce qu'un raccourcisseur fait de tout cela sur le fil, voir comment fonctionnent les raccourcisseurs d'URL.

Ce que dit vraiment la RFC 3986 sur la longueur des URL

La RFC 3986 définit la syntaxe générique des URI - schéma, autorité, chemin, requête, fragment - et elle reste silencieuse sur la longueur que chacun peut atteindre. Pas silencieuse par omission ; silencieuse par conception. La grammaire de la section 3 construit une URI à partir d'un petit ensemble de règles de production, et rien dans ces règles ne plafonne le nombre de fois qu'une règle peut se répéter. Un segment de chemin peut faire un caractère ou cent mille, du point de vue de la syntaxe. Les URL longues sont des URL parfaitement légales.

La seule limite qu'impose réellement la RFC est indirecte : le composant autorité d'une URL inclut un nom d'hôte, et le DNS plafonne un nom d'hôte pleinement qualifié bien en dessous de ce que permet la grammaire URI - la documentation d'ingénierie de Chromium fixe ce plafond à 253 caractères au total, 63 par étiquette. Le chemin, la chaîne de requête et le fragment ne portent aucune contrainte de ce type nulle part dans la norme.

C'est toute l'histoire du côté de la norme. La limite de caractères d'URL que vous rencontrez réellement en pratique vient du logiciel qui lit l'URL, jamais du format de l'URL lui-même.

D'où vient le chiffre 2 083, et ce que font les navigateurs aujourd'hui

Si vous avez déjà vu une recommandation sur la longueur d'URL quelque part, elle citait 2 083 caractères. Ce chiffre est réel, mais il appartient à un seul navigateur, une seule époque, et un seul chemin de code. La bibliothèque réseau WinINET d'Internet Explorer définissait INTERNET_MAX_URL_LENGTH à 2083 caractères, et l'article technique de Microsoft sur cette limite note que la barre d'adresse elle-même était plafonnée un caractère plus bas, à 2047. Ce plafond a régi une énorme part du trafic web pendant plus d'une décennie, si bien qu'il est devenu le chiffre auquel tout le monde concevait, et l'habitude a survécu au navigateur qu'elle décrit.

Les navigateurs modernes ne fonctionnent pas ainsi. La documentation de Chrome indique une limite interne de 2 mégaoctets, imposée pour éviter des problèmes de communication inter-processus plutôt que pour protéger un champ d'interface, avec une constante bien plus petite, autour de 32 kilo-octets sur ordinateur de bureau, qui plafonne ce que l'omnibox affichera réellement. Firefox et Safari sont tout aussi généreux - aucun des deux ne s'étouffe sur une URL même proche de la longueur que vous êtes susceptible de construire à la main. Je n'ai jamais, une seule fois, débogué un vrai problème de production causé par un navigateur moderne refusant une URL longue. Chaque bug lié à une URL longue que j'ai retracé a commencé en aval du navigateur.

Les limites concrètes qui mordent réellement

Alignez les endroits qu'une URL traverse réellement et un motif apparaît vite : la limite la plus stricte est rarement celle du navigateur.

• La ligne de requête du serveur lit l'URL comme faisant partie de la première ligne d'une requête HTTP, et cette ligne a son propre tampon. Dépassez-la et le serveur n'analyse jamais votre route - il refuse la connexion avant même que votre code applicatif ne s'exécute.
• Les clients de messagerie gèrent le dépassement différemment. Outlook replie une longue URL en texte brut sur plusieurs lignes plutôt que de la tronquer, ce qui est laid mais reste cliquable ; certains webmails et passerelles de transfert sont moins indulgents et coupent le lien net.
• Un lien à l'intérieur d'un texto est en concurrence avec le corps du message pour le même budget de caractères, et les liens marketing par SMS vivent à l'intérieur d'un segment de 160 caractères - une longue URL à elle seule peut faire passer un texto d'un segment à deux, ce que les opérateurs facturent et filtrent différemment.
• Un code QR ne tronque pas une longue URL ; il devient simplement plus dense. La taille nécessaire d'un code QR dépend directement de ce que vous lui demandez d'encoder, et une URL chargée de paramètres de suivi peut faire grimper un code d'une version ou deux, réduisant la distance à laquelle il pourra encore être scanné.
• Les fonctions d'hyperlien des tableurs imposent leur propre limite stricte de caractères sur l'argument du lien, bien en deçà d'une URL taguée typique, et un lien qui la dépasse échoue silencieusement - la cellule s'affiche normalement, mais le lien lui-même ne fonctionne pas.
• Les plateformes publicitaires plafonnent le champ d'URL de destination à une longueur fixe de leur choix, une règle de plateforme plutôt que technique, et un gestionnaire de campagne ne le découvre qu'au moment où le bouton d'enregistrement rejette ce qu'un navigateur ouvrirait sans broncher.

Aucune de ces limites ne communique avec les autres. Une URL peut passer la ligne de requête de votre serveur et mourir malgré tout dans un tableur, trois services plus loin.

Les limites de la ligne de requête, côté serveur et proxy

Le cas du serveur mérite un examen à part, car c'est celui qui produit un vrai code d'erreur plutôt qu'un simple défaut cosmétique. 414 Request-URI Too Long est la réponse qu'un serveur envoie lorsqu'il refuse de traiter une requête parce que l'URI est plus longue que ce qu'il veut bien interpréter - une limite de taille d'URL appliquée un saut à la fois, par le logiciel qui lit la ligne de requête à cet instant précis.

Chaque serveur et proxy de la chaîne applique sa propre version de cette règle. La directive LimitRequestLine d'Apache vaut par défaut 8 190 octets pour la ligne de requête entière, ce qui inclut la méthode et la version du protocole, pas seulement l'URL elle-même. nginx lit les en-têtes de requête dans un tampon fixe contrôlé par large_client_header_buffers, 8 kilo-octets par défaut, et une ligne de requête qui ne tient pas dedans reçoit un 414 avant même que votre route ne corresponde. Les répartiteurs de charge et les CDN placés devant l'un ou l'autre appliquent souvent une troisième limite, distincte, si bien qu'une URL peut passer le réglage de votre serveur d'origine et se faire quand même rejeter un saut plus tôt.

Si vous ne contrôlez pas chaque saut, et passé une certaine taille d'entreprise personne ne le fait, le choix prudent consiste à concevoir pour le plus strict des réglages par défaut communs plutôt que pour le plus généreux que vous avez trouvé dans un fichier de configuration.

Construire vous-même la couche de redirection plutôt que de bricoler l'analyse des requêtes est ici la solution la moins spectaculaire mais la plus fiable. L'API d'Elido accepte une destination de n'importe quelle longueur raisonnable et renvoie un lien court dont la taille ne change jamais, si bien que le plafond de la ligne de requête d'un serveur devient quelque chose que vous configurez une fois en périphérie plutôt qu'un problème que chaque intégration doit gérer seule.

Comment mesurer la vraie longueur d'une URL avant de l'envoyer

Le nombre de caractères est toute la mesure, et il vaut mieux le vérifier avant qu'une URL n'entre dans une campagne plutôt qu'après la réception d'un rapport de rebond.

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

Cela vous donne la longueur en octets de l'URL exactement telle qu'écrite. Deux choses compliquent la chose. D'abord, les caractères encodés en pourcentage coûtent plus cher qu'il n'y paraît : une lettre accentuée ou un emoji à l'intérieur d'une valeur de requête peut s'étendre à six caractères ou plus une fois encodé, donc mesurez l'URL après encodage, pas avant. Ensuite, les paramètres UTM sont généralement la partie d'une URL qui grossit le plus vite - une poignée de balises de campagne, source, support et contenu peut ajouter plusieurs centaines de caractères à ce qui était au départ un chemin court, et c'est le premier endroit à regarder quand une URL a discrètement grossi trop longtemps.

Si un lien qui fonctionnait auparavant cesse soudain de fonctionner, effectuez la même vérification que pour n'importe quel lien mort : lien court qui ne fonctionne pas détaille comment vérifier directement la destination, ce qui est exactement la manière dont vous repéreriez une URL ayant dépassé la limite d'un serveur, un paramètre de suivi à la fois.

Que faire quand une URL est trop longue

Deux solutions fonctionnent réellement, et ce sont les mêmes deux quelle que soit la limite que vous avez déclenchée.

La première consiste à raccourcir l'URL. Un lien court est un pointeur de longueur fixe - le slug garde la même longueur quelle que soit la croissance de la destination ou de ses paramètres de suivi, parce que tout cela vit côté serveur et est recherché à chaque clic plutôt que transporté à l'intérieur du lien lui-même. Cela résout d'un seul coup le problème de densité des codes QR, le problème des segments SMS, et le problème des tableurs, puisque tous trois se soucient du nombre de caractères du lien, pas de la longueur de l'endroit où il pointe finalement.

La seconde consiste à sortir entièrement l'état de la chaîne de requête. Si ce qui allonge votre URL, ce sont des données de session, un gros bloc de contenu de panier, ou une longue liste de filtres plutôt que de véritables paramètres de suivi, ces données ont généralement leur place côté serveur derrière un identifiant opaque, pas écrites en toutes lettres dans la barre d'adresse. Une URL du type /checkout?session=a1b2c3d4 vieillit mieux qu'une URL du type /checkout?items=... avec chaque référence et quantité écrite en entier, et elle contourne d'un coup toutes les limites de cet article, parce qu'il ne reste plus rien de long à mesurer.

Les deux solutions pointent dans la même direction : traiter la longueur d'une URL comme une décision de conception, pas comme le hasard du nombre de paramètres qui s'y sont accumulés.

Lisez la série pilier

Cet article s'inscrit dans le cluster ingénierie. Pour ce qui se passe à l'autre bout d'un lien court, comment fonctionnent les raccourcisseurs d'URL couvre la recherche elle-même, et types de redirections couvre les codes de statut impliqués une fois la destination trouvée.

Sur le blog

• L'encodage d'URL expliqué : quels caractères échapper
• Les paramètres UTM expliqués, avec un schéma de nommage qui survit
• Quelle taille pour un code QR ? Règles de taille et de distance
• Un raccourcisseur d'URL pour le SMS marketing que les opérateurs approuvent
• Lien court qui ne fonctionne pas ? Diagnostic en une commande