Longitud máxima de una URL: el límite real de caracteres

No hay una longitud máxima de URL. RFC 3986, el estándar que define la sintaxis de las URI, nunca fija una - describe qué caracteres son legales y cómo se ensambla una URL, y ahí se detiene. Con lo que realmente te encuentras es con una cadena de límites separados y sin relación entre sí: la barra de direcciones de tu navegador, el servidor web al otro lado, el proxy que se sienta entre ambos, el cliente de correo en el que alguien abre tu enlace, o el código QR que estás a punto de imprimir. Cada uno impone su propio límite, y la longitud máxima real de una URL es la del límite más bajo. Envía una URL de 3.000 caracteres y puede que se muestre bien en Chrome, que un servidor la rechace con la configuración por defecto, y que llegue a Outlook envuelta en cuatro líneas. Nada de eso es un fallo. Es la consecuencia práctica de un estándar que guardó silencio deliberadamente sobre la cuestión.

De ahí se derivan cuatro cosas: lo que el estándar dice y lo que no dice, de dónde viene el famoso número de 2.083 caracteres y por qué sigue apareciendo en listas de verificación años después de haber dejado de importar, los límites que realmente muerden en cuanto un enlace sale del navegador, y qué hacer con una URL que ha crecido demasiado. Para saber qué hace un acortador con todo esto en el camino, consulta cómo funcionan los acortadores de URL.

Lo que RFC 3986 dice realmente sobre la longitud de una URL

RFC 3986 define la sintaxis genérica de las URI - esquema, autoridad, ruta, consulta, fragmento - y guarda silencio sobre cuánto puede extenderse cualquiera de ellas. No es un silencio por omisión, sino un silencio deliberado. La gramática de la sección 3 construye una URI a partir de un pequeño conjunto de reglas de producción, y ninguna de esas reglas limita cuántas veces puede repetirse una regla. Un segmento de ruta puede tener un carácter o cien mil, en lo que respecta a la sintaxis. Las URLs largas son URLs perfectamente legales.

El único límite que la RFC sí impone es indirecto: el componente de autoridad de una URL incluye un nombre de host, y el DNS limita un nombre de host totalmente cualificado muy por debajo de lo que permite la gramática de la URI - la documentación de ingeniería de Chromium sitúa ese límite en 253 caracteres en total, 63 por etiqueta. La ruta, la cadena de consulta y el fragmento no llevan ninguna restricción de ese tipo en ninguna parte del estándar.

Esa es toda la historia por parte del estándar. El límite de caracteres de una URL con el que realmente te topas en la práctica viene del software que lee la URL, nunca del propio formato de la URL.

De dónde viene el 2.083, y qué hacen ahora los navegadores

Si alguna vez has visto una directriz sobre la longitud de una URL en algún sitio, citaba 2.083 caracteres. Ese número es real, pero pertenece a un navegador, una época y una ruta de código concretos. La librería de red WinINET de Internet Explorer definía INTERNET_MAX_URL_LENGTH como 2083 caracteres, y el propio artículo técnico de Microsoft sobre el límite señala que la propia barra de direcciones estaba limitada un carácter menos, en 2047. Ese límite gobernó una enorme parte del tráfico web durante más de una década, así que se convirtió en el número para el que todo el mundo diseñaba, y la costumbre sobrevivió al navegador que describe.

Los navegadores modernos no funcionan así. La documentación de Chrome indica un límite interno de 2 megabytes, impuesto para evitar problemas de comunicación entre procesos y no para proteger un campo de la interfaz, con una constante mucho menor, alrededor de 32 kilobytes en escritorio, que limita lo que el omnibox llega a mostrar. Firefox y Safari son igual de generosos - ninguno de los dos se atraganta con una URL ni de lejos tan larga como la que probablemente construyas a mano. Nunca en mi carrera he tenido que depurar un problema real de producción causado por un navegador moderno que rechazara una URL larga. Todos los fallos de URL larga que he rastreado empezaban río abajo del navegador.

Los límites del mundo real que realmente muerden

Alinea por dónde viaja realmente una URL y un patrón aparece enseguida: el límite más estricto rara vez es el del navegador.

• La línea de solicitud del servidor lee la URL como parte de la primera línea de una solicitud HTTP, y esa línea tiene su propio búfer. Sobrepásalo y el servidor nunca llega a analizar tu ruta - rechaza la conexión antes de que tu código de aplicación llegue siquiera a ejecutarse.
• Los clientes de correo gestionan el desbordamiento de forma distinta. Outlook envuelve una URL larga en texto plano en varias líneas en lugar de truncarla, lo cual es feo pero sigue siendo pulsable; algunos clientes de webmail y pasarelas de reenvío son menos indulgentes y cortan el enlace sin más.
• Un enlace dentro de un mensaje de texto compite con el cuerpo del mensaje por el mismo presupuesto de caracteres, y los enlaces de marketing por SMS viven dentro de un segmento de 160 caracteres - una URL larga por sí sola puede hacer que un texto de un segmento pase a dos, algo que las operadoras facturan y filtran de forma distinta.
• Un código QR no trunca una URL larga; simplemente se vuelve más denso. Qué tamaño necesita tener un código QR depende directamente de cuánto le pidas que codifique, y una URL cargada de parámetros de seguimiento puede subir un código una versión o dos, reduciendo la distancia desde la que se seguirá escaneando.
• Las funciones de hipervínculo de las hojas de cálculo imponen su propio límite estricto de caracteres en el argumento del enlace, muy por debajo de una URL etiquetada típica, y un enlace que lo supera falla en silencio - la celda se muestra bien, pero el enlace en sí no funciona.
• Las plataformas publicitarias limitan el campo de URL de destino a una longitud fija elegida por ellas mismas, una regla de la plataforma más que técnica, y quien gestiona la campaña solo se entera cuando el botón de guardar rechaza lo que un navegador abriría sin rechistar.

Ninguno de estos límites se comunica con los demás. Una URL puede superar la línea de solicitud de tu servidor y aun así morir en una hoja de cálculo tres departamentos después.

Límites de la línea de solicitud en servidores y proxies

El caso del servidor merece su propio análisis, porque es el que produce un código de error real en lugar de un fallo cosmético. 414 Request-URI Too Long es la respuesta que envía un servidor cuando se niega a procesar una solicitud porque la URI es más larga de lo que está dispuesto a interpretar - un límite de tamaño de URL que se impone salto a salto, según qué software esté leyendo la línea de solicitud en ese momento.

Cada servidor y proxy de la cadena impone su propia versión de esto. La directiva LimitRequestLine de Apache tiene por defecto 8.190 bytes para toda la línea de solicitud, lo que incluye el método y la versión del protocolo, no solo la URL en sí. nginx lee las cabeceras de la solicitud en un búfer fijo controlado por large_client_header_buffers, 8 kilobytes por defecto, y una línea de solicitud que no cabe recibe un 414 antes de que tu ruta llegue siquiera a coincidir. Los balanceadores de carga y las CDN que están delante de cualquiera de los dos suelen aplicar un tercer límite, separado, así que una URL puede superar la configuración de tu servidor de origen y aun así ser rechazada un salto antes.

Si no controlas todos los saltos - y a partir de cierto tamaño de empresa nadie lo hace -, lo prudente es diseñar para el valor por defecto común más estricto, no para el más generoso que encontraste en un archivo de configuración.

Construir tú mismo la capa de redirección en lugar de programar a mano el análisis de solicitudes es la solución aburrida pero eficaz. La API de Elido acepta un destino de cualquier longitud razonable y devuelve un enlace corto que nunca cambia de tamaño, de modo que el límite de línea de solicitud de un servidor se convierte en algo que configuras una vez en el edge en lugar de algo que cada integración tiene que gestionar por su cuenta.

Cómo medir la longitud real de una URL antes de publicarla

El recuento de caracteres es toda la medición, y merece la pena comprobarlo antes de que una URL entre en una campaña, no después de que llegue un informe de rebotes.

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

Eso te da la longitud en bytes de la URL exactamente tal como está escrita. Dos cosas lo complican. Primero, los caracteres codificados en porcentaje cuestan más de lo que parece: una letra acentuada o un emoji dentro de un valor de consulta puede expandirse a seis caracteres o más una vez codificado, así que mide la URL después de codificarla, no antes. Segundo, los parámetros UTM suelen ser la parte de una URL que más rápido crece - un puñado de etiquetas de campaña, origen, medio y contenido puede añadir varios cientos de caracteres a lo que empezó como una ruta corta, y son el primer sitio donde mirar cuando una URL ha crecido demasiado en silencio.

Si un enlace que antes funcionaba deja de hacerlo de repente, sigue el mismo rastreo que usarías para cualquier enlace muerto: el enlace corto no funciona explica paso a paso cómo comprobar el destino directamente, que es exactamente cómo detectarías una URL que ha superado el límite de un servidor parámetro de seguimiento a parámetro de seguimiento.

Qué hacer cuando una URL es demasiado larga

Solo dos soluciones funcionan de verdad, y son las mismas dos sin importar qué límite hayas hecho saltar.

La primera es acortar la URL. Un enlace corto es un puntero de longitud fija - el slug mantiene la misma longitud sin importar cuánto crezcan el destino o sus parámetros de seguimiento, porque todo eso vive en el servidor y se consulta en cada clic en lugar de viajar dentro del propio enlace. Eso resuelve de una sola vez el problema de la densidad del código QR, el problema del segmento SMS y el problema de la hoja de cálculo, ya que a los tres les importa el recuento de caracteres del enlace, no la longitud de a dónde acaba apuntando.

La segunda es sacar por completo el estado de la cadena de consulta. Si lo que alarga tu URL son datos de sesión, un bloque con el contenido de un carrito o una lista larga de filtros en lugar de parámetros de seguimiento genuinos, esos datos normalmente pertenecen al servidor, detrás de un ID opaco, no escritos en la barra de direcciones. Una URL que dice /checkout?session=a1b2c3d4 envejece mejor que una que dice /checkout?items=... con cada SKU y cantidad escritos por completo, y esquiva de golpe todos los límites de este artículo, porque ya no queda nada largo que medir.

Ambas soluciones apuntan en la misma dirección: trata la longitud de una URL como una decisión de diseño, no como un accidente de cuántos parámetros se acumularon en ella por casualidad.

Lee la serie central

Este artículo pertenece al clúster de ingeniería. Para lo que pasa al otro lado de un enlace corto, cómo funcionan los acortadores de URL cubre la propia búsqueda, y tipos de redirecciones de URL cubre los códigos de estado implicados una vez que se encuentra el destino.

Relacionados en el blog

• Codificación de URL explicada: qué caracteres hay que escapar
• Parámetros UTM explicados, con un esquema de nomenclatura que sobrevive
• ¿Qué tamaño debe tener un código QR? Reglas de tamaño y distancia
• Acortador de URL para marketing por SMS en el que confían las operadoras
• ¿El enlace corto no funciona? Diagnostícalo con un solo comando