Comprimento Máximo de URL: O Limite Real de Caracteres

Não existe um comprimento máximo de URL. A RFC 3986, o padrão que define a sintaxe de URI, nunca define um - ela descreve quais caracteres são válidos e como uma URL é montada, e para por aí. O que você de fato encontra é uma cadeia de limites separados e independentes: a barra de endereço do seu navegador, o servidor web do outro lado, o proxy no meio do caminho, o cliente de email em que alguém abre seu link, ou o código QR que você está prestes a imprimir. Cada um deles impõe seu próprio limite, e o comprimento máximo real de uma URL é o do limite mais baixo entre eles. Publique uma URL de 3.000 caracteres e ela pode renderizar perfeitamente no Chrome, ser rejeitada por um servidor com configurações padrão, e chegar ao Outlook quebrada em quatro linhas. Nada disso é um bug. É a consequência prática de uma especificação que foi deliberadamente silenciosa sobre a questão.

Daí decorrem quatro coisas: o que o padrão diz e o que não diz, de onde veio o famoso número de 2.083 caracteres e por que ele ainda aparece em checklists anos depois de deixar de importar, os limites que realmente mordem depois que um link sai do navegador, e o que fazer com uma URL que cresceu demais. Para entender o que um encurtador faz com tudo isso no meio do caminho, veja como funcionam os encurtadores de URL.

O Que a RFC 3986 Realmente Diz Sobre o Comprimento de URL

A RFC 3986 define a sintaxe genérica para URIs - esquema, autoridade, caminho, query, fragmento - e é silenciosa sobre quanto qualquer uma dessas partes pode se estender. Silenciosa não por omissão; silenciosa por design. A gramática na seção 3 constrói uma URI a partir de um pequeno conjunto de regras de produção, e nada nessas regras limita quantas vezes uma regra pode se repetir. Um segmento de caminho pode ter um caractere ou cem mil, no que diz respeito à sintaxe. URLs longas são URLs perfeitamente válidas.

O único limite que a RFC de fato impõe é indireto: o componente de autoridade de uma URL inclui um hostname, e o DNS limita um hostname totalmente qualificado bem abaixo do que a gramática da URI permite - a documentação de engenharia do Chromium coloca esse limite em 253 caracteres no total, 63 por rótulo. Caminho, query string e fragmento não carregam nenhuma restrição desse tipo em lugar nenhum do padrão.

Essa é toda a história do lado da especificação. O limite de caracteres de URL que você de fato encontra na prática vem do software que lê a URL, nunca do formato da URL em si.

De Onde Veio o 2.083, e o Que os Navegadores Fazem Hoje

Se você já viu uma diretriz de comprimento de URL em algum lugar, ela citava 2.083 caracteres. Esse número é real, mas pertence a um navegador, uma época e um caminho de código específicos. A biblioteca de rede WinINET do Internet Explorer definia INTERNET_MAX_URL_LENGTH como 2083 caracteres, e o próprio relato técnico da Microsoft sobre o limite observa que a barra de endereço em si era limitada um caractere abaixo, em 2047. Esse teto governou uma enorme parte do tráfego da web por mais de uma década, então virou o número para o qual todo mundo projetava, e o hábito sobreviveu ao navegador que ele descreve.

Navegadores modernos não funcionam assim. A documentação do Chrome afirma um limite interno de 2 megabytes, imposto para evitar problemas de comunicação entre processos e não para proteger um campo de interface, com uma constante bem menor, cerca de 32 kilobytes no desktop, limitando o que o omnibox realmente exibe. Firefox e Safari são igualmente generosos - nenhum dos dois engasga com uma URL nem perto do comprimento que você provavelmente construiria à mão. Eu nunca depurei um problema real de produção causado por um navegador moderno recusando uma URL longa. Todo bug de URL longa que já rastreei começou depois do navegador, mais adiante na cadeia.

Os Limites do Mundo Real Que Realmente Mordem

Alinhe por onde uma URL realmente passa e um padrão aparece rápido: o limite mais apertado raramente é o do navegador.

• A linha de requisição do servidor lê a URL como parte da primeira linha de uma requisição HTTP, e essa linha tem seu próprio buffer. Ultrapasse esse limite e o servidor nunca chega a interpretar sua rota - ele recusa a conexão antes mesmo do código da sua aplicação rodar.
• Clientes de email lidam com o excesso de forma diferente. O Outlook quebra uma URL longa em texto simples em várias linhas em vez de truncá-la, o que é feio mas ainda clicável; alguns webmails e gateways de encaminhamento são menos tolerantes e simplesmente cortam o link.
• Um link dentro de uma mensagem de texto compete com o corpo da mensagem pelo mesmo orçamento de caracteres, e os links de marketing por SMS vivem dentro de um segmento de 160 caracteres - uma URL longa sozinha pode empurrar um texto de um segmento para dois, e as operadoras cobram e filtram isso de forma diferente.
• Um código QR não trunca uma URL longa; ele simplesmente fica mais denso. O quão grande um código QR precisa ser depende diretamente de quanto você pede para ele codificar, e uma URL carregada de parâmetros de rastreamento pode empurrar um código uma ou duas versões acima, reduzindo a distância de onde ele ainda vai ser lido.
• Funções de hyperlink de planilhas impõem seu próprio limite rígido de caracteres no argumento do link, bem abaixo de uma URL típica com parâmetros de rastreamento, e um link que ultrapassa isso falha silenciosamente - a célula exibe normalmente, mas o link em si não funciona.
• Plataformas de anúncios limitam o campo de URL de destino a um comprimento fixo de sua própria escolha, uma regra da plataforma e não uma restrição técnica, e quem gerencia a campanha só descobre isso quando o botão de salvar rejeita o que um navegador abriria sem reclamar.

Nenhum desses limites conversa entre si. Uma URL pode passar tranquilamente pela linha de requisição do seu servidor e ainda assim morrer numa planilha três departamentos depois.

Limites de Linha de Requisição de Servidores e Proxies

O caso do servidor merece um olhar à parte, porque é o único que produz um código de erro de verdade em vez de uma falha cosmética. 414 Request-URI Too Long é a resposta que um servidor envia quando se recusa a processar uma requisição porque a URI é mais longa do que ele está disposto a interpretar - um limite de tamanho de URL imposto um salto de cada vez, por qualquer que seja o software lendo a linha de requisição naquele instante.

Cada servidor e proxy na cadeia impõe sua própria versão disso. A diretiva LimitRequestLine do Apache tem como padrão 8.190 bytes para toda a linha de requisição, o que inclui o método e a versão do protocolo, não só a URL em si. O nginx lê os cabeçalhos da requisição em um buffer fixo controlado por large_client_header_buffers, 8 kilobytes por padrão, e uma linha de requisição que não cabe recebe um 414 antes mesmo de sua rota ser identificada. Balanceadores de carga e CDNs na frente de qualquer um desses dois costumam aplicar um terceiro limite, separado, então uma URL pode passar pela configuração do seu servidor de origem e ainda assim ser rejeitada um salto antes.

Se você não controla cada salto - e a partir de um certo tamanho de empresa ninguém controla - a jogada segura é projetar para o padrão comum mais apertado, e não para o mais generoso que você encontrou em um arquivo de configuração.

Construir a camada de redirecionamento você mesmo em vez de escrever manualmente o parsing de requisições é a solução chata aqui. A API da Elido aceita um destino de qualquer comprimento razoável e devolve um link curto que nunca muda de tamanho, então o limite de linha de requisição de um servidor vira algo que você configura uma vez na borda, em vez de algo que cada integração precisa resolver por conta própria.

Como Medir o Comprimento Real de uma URL Antes de Publicá-la

A contagem de caracteres é toda a medição, e vale a pena verificar antes de a URL entrar numa campanha, e não depois de um relatório de rejeição chegar.

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

Isso te dá o comprimento em bytes da URL exatamente como ela foi escrita. Duas coisas complicam essa conta. Primeiro, caracteres codificados com percent-encoding custam mais do que parecem: uma letra acentuada ou um emoji dentro de um valor de query pode se expandir para seis caracteres ou mais depois de codificado, então meça a URL depois da codificação, não antes. Segundo, os parâmetros UTM costumam ser a parte que mais cresce numa URL - um punhado de tags de campanha, origem, meio e conteúdo pode acrescentar várias centenas de caracteres a um caminho que começou curto, e é o primeiro lugar para olhar quando uma URL cresceu demais sem que ninguém percebesse.

Se um link que costumava funcionar de repente parou, faça a mesma investigação que você faria para qualquer link morto: link curto não funciona mostra passo a passo como verificar o destino diretamente, que é exatamente como você pegaria uma URL que cresceu além do limite de um servidor um parâmetro de rastreamento de cada vez.

O Que Fazer Quando uma URL Está Longa Demais

Duas soluções realmente funcionam, e são as mesmas duas não importa qual limite você tenha atingido.

A primeira é encurtar a URL. Um link curto é um ponteiro de comprimento fixo - o slug mantém o mesmo tamanho não importa o quanto o destino ou seus parâmetros de rastreamento cresçam, porque tudo isso vive no lado do servidor e é consultado a cada clique em vez de ser carregado dentro do próprio link. Isso resolve o problema de densidade do código QR, o problema do segmento de SMS e o problema da planilha de uma só vez, já que os três se importam com a contagem de caracteres do link, não com o comprimento de para onde ele eventualmente aponta.

A segunda é tirar o estado da query string por completo. Se o que está deixando sua URL longa é dado de sessão, um blob com o conteúdo de um carrinho, ou uma lista longa de filtros, em vez de parâmetros de rastreamento de verdade, esse dado geralmente pertence ao lado do servidor, por trás de um ID opaco, e não escrito por extenso na barra de endereço. Uma URL como /checkout?session=a1b2c3d4 envelhece melhor do que uma como /checkout?items=... com cada SKU e quantidade escritos por extenso, e ela contorna todos os limites deste artigo de uma vez, porque não sobra nada longo para medir.

As duas soluções apontam para a mesma direção: trate o comprimento de uma URL como uma decisão de design, não como um acidente de quantos parâmetros acabaram se acumulando nela.

Leia a Série Principal

Este post está no cluster de engenharia. Para o que acontece do outro lado de um link curto, como funcionam os encurtadores de URL cobre a busca em si, e tipos de redirecionamento de URL cobre os códigos de status envolvidos depois que o destino é encontrado.

Relacionados no blog

• Codificação de URL explicada: quais caracteres escapar
• Parâmetros UTM explicados, com um esquema de nomenclatura que se sustenta
• Qual deve ser o tamanho de um código QR? Regras de tamanho e distância
• Encurtador de URL para marketing por SMS que as operadoras confiam
• Link curto não funciona? Diagnostique em um comando