Maximale URL-lengte: de tekenlimiet in de praktijk

Er is geen maximale URL-lengte. RFC 3986, de standaard die URI-syntax definieert, legt er nooit een vast - hij beschrijft welke tekens toegestaan zijn en hoe een URL wordt opgebouwd, en stopt daar. Waar je in de praktijk tegenaan loopt, is een keten van losstaande, ongerelateerde limieten: de adresbalk van je browser, de webserver aan de andere kant, de proxy daartussenin, de e-mailclient waarin iemand je link opent, of de QR-code die je op het punt staat te printen. Elk daarvan legt zijn eigen plafond op, en de werkelijke maximale lengte van een URL is welk plafond dan ook het laagst ligt. Verstuur een URL van 3.000 tekens en die kan prima renderen in Chrome, worden geweigerd door een server met standaardinstellingen, en in Outlook aankomen afgebroken over vier regels. Niets daarvan is een bug. Het is het praktische gevolg van een spec die bewust zweeg over de vraag.

Daaruit volgen vier dingen: wat de standaard wel en niet zegt, waar het beroemde getal van 2.083 tekens vandaan komt en waarom het jaren nadat het niet meer relevant was nog steeds opduikt in checklists, de limieten die er echt toe doen zodra een link de browser verlaat, en wat je moet doen met een URL die te lang is geworden. Voor wat een shortener hiermee doet onderweg, zie hoe URL-verkorters werken.

Wat RFC 3986 daadwerkelijk zegt over URL-lengte

RFC 3986 definieert de generieke syntax voor URI's - scheme, authority, pad, query, fragment - en zwijgt over hoe lang elk daarvan mag zijn. Niet stil door verzuim; stil met opzet. De grammatica in sectie 3 bouwt een URI op uit een kleine set productieregels, en niets in die regels beperkt hoe vaak een regel mag herhalen. Wat de syntax betreft kan een padsegment een teken lang zijn of honderdduizend. Lange URL's zijn volkomen legale URL's.

De ene limiet die de RFC wel oplegt, is indirect: het authority-onderdeel van een URL bevat een hostname, en DNS beperkt een volledig gekwalificeerde hostname tot ruim onder wat de URI-grammatica toestaat - de technische documentatie van Chromium legt dat plafond op 253 tekens in totaal, 63 per label. Pad, querystring en fragment kennen nergens in de standaard zo'n beperking.

Dat is het hele verhaal vanuit de spec bekeken. De URL-tekenlimiet waar je in de praktijk daadwerkelijk tegenaan loopt, komt van de software die de URL leest, nooit van het URL-formaat zelf.

Waar 2.083 vandaan kwam, en wat browsers nu doen

Als je ooit ergens een richtlijn voor URL-lengte hebt gezien, citeerde die 2.083 tekens. Dat getal is echt, maar het hoort bij een browser, een tijdperk en een codepad. De WinINET-netwerkbibliotheek van Internet Explorer definieerde INTERNET_MAX_URL_LENGTH als 2083 tekens, en Microsofts eigen technische toelichting op de limiet merkt op dat de adresbalk zelf een teken lager lag, op 2047. Dat plafond bepaalde meer dan tien jaar lang een enorm deel van het webverkeer, dus werd het het getal waar iedereen op ontwierp, en de gewoonte overleefde de browser die hij beschrijft.

Moderne browsers werken niet zo. De documentatie van Chrome vermeldt een interne limiet van 2 megabyte, opgelegd om problemen met interprocescommunicatie te voorkomen en niet om een UI-veld te beschermen, met een veel kleinere constante, ongeveer 32 kilobyte op desktop, die beperkt wat de omnibox daadwerkelijk weergeeft. Firefox en Safari zijn even genereus - geen van beide verslikt zich in een URL die ook maar in de buurt komt van de lengte die je met de hand zou construeren. Ik heb nog nooit een echt productieprobleem gedebugd dat werd veroorzaakt doordat een moderne browser een lange URL weigerde. Elke bug rond lange URL's die ik heb getraceerd, begon stroomafwaarts van de browser.

De limieten uit de praktijk die er echt toe doen

Zet op een rij waar een URL daadwerkelijk doorheen reist, en er duikt snel een patroon op: de strengste limiet zit zelden in de browser.

• De requestregel van de server leest de URL als onderdeel van de eerste regel van een HTTP-request, en die regel heeft zijn eigen buffer. Overschrijd die en de server parseert je route nooit - hij weigert de verbinding voordat je applicatiecode ook maar draait.
• E-mailclients gaan verschillend om met overloop. Outlook breekt een lange platte-tekst-URL af over meerdere regels in plaats van hem af te kappen, wat lelijk is maar nog steeds klikbaar; sommige webmailclients en forwarding-gateways zijn minder vergevingsgezind en knippen de link gewoon af.
• Een link in een sms concurreert met de berichttekst om hetzelfde tekenbudget, en sms-marketinglinks leven binnen een segment van 160 tekens - een lange URL alleen al kan een sms van een segment naar twee duwen, en providers factureren en filteren die anders.
• Een QR-code kapt een lange URL niet af; hij wordt gewoon dichter. Hoe groot een QR-code moet zijn hangt rechtstreeks af van hoeveel je hem vraagt te coderen, en een URL volgeladen met trackingparameters kan een code een versie of twee omhoog duwen, waardoor de afstand waarop hij nog scant kleiner wordt.
• Hyperlinkfuncties in spreadsheets hanteren hun eigen harde tekenlimiet voor het linkargument, ruim onder een typische getagde URL, en een link die daar overheen gaat, faalt stilletjes - de cel ziet er prima uit, de link zelf werkt niet.
• Advertentieplatforms beperken het bestemmings-URL-veld tot een vaste lengte van hun eigen keuze, een platformregel eerder dan een technische, en een campagnebeheerder komt daar pas achter wanneer de opslaanknop weigert wat een browser zonder klagen zou openen.

Geen van deze limieten communiceert met elkaar. Een URL kan de requestregel van je server prima doorstaan en toch sneuvelen in een spreadsheet drie afdelingen verderop.

Requestregel-limieten van server en proxy

Het geval van de server verdient een eigen blik, omdat dat degene is die een echte foutcode oplevert in plaats van een cosmetisch mankement. 414 Request-URI Too Long is de response die een server stuurt wanneer hij weigert een request te verwerken omdat de URI langer is dan hij bereid is te interpreteren - een URL-groottelimiet die per hop wordt gehandhaafd, door welke software dan ook die op dat moment de requestregel leest.

Elke server en proxy in de keten handhaaft zijn eigen versie hiervan. De directive LimitRequestLine van Apache staat standaard op 8.190 bytes voor de volledige requestregel, wat de methode en protocolversie omvat, niet alleen de URL zelf. Nginx leest requestheaders in een vaste buffer die wordt beheerd door large_client_header_buffers, standaard 8 kilobyte, en een requestregel die daar niet in past, krijgt een 414 voordat je route ooit matcht. Load balancers en CDN's die daarvoor staan, passen vaak een derde, aparte limiet toe, waardoor een URL de instelling van je origin-server kan doorstaan en toch een hop eerder geweigerd wordt.

Als je niet elke hop beheert - en voorbij een bepaalde bedrijfsgrootte doet niemand dat - is de veilige zet om te ontwerpen voor de strengste gangbare standaardwaarde in plaats van de meest genereuze die je in een configuratiebestand hebt gevonden.

Zelf een redirectlaag bouwen in plaats van requestparsing met de hand te doen, is hier de saaie oplossing. De API van Elido accepteert een bestemming van elke redelijke lengte en levert een korte link terug die nooit van grootte verandert, waardoor het requestregel-plafond van een server iets wordt dat je een keer configureert op de edge in plaats van iets wat elke integratie zelf moet afhandelen.

Hoe je de werkelijke lengte van een URL meet voordat je hem verstuurt

Het aantal tekens is de hele meting, en het is de moeite waard om dat te controleren voordat een URL in een campagne gaat, in plaats van nadat een bounce-rapport binnenkomt.

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

Dat geeft je de bytelengte van de URL precies zoals geschreven. Twee dingen maken het lastiger. Ten eerste kosten percent-encoded tekens meer dan ze eruitzien: een letter met accent of een emoji binnen een querywaarde kan na codering uitzetten naar zes tekens of meer, dus meet de URL na het coderen, niet ervoor. Ten tweede zijn UTM-parameters meestal het snelst groeiende deel van een URL - een handvol campaign-, source-, medium- en content-tags kan enkele honderden tekens toevoegen aan wat begon als een kort pad, en dat is de eerste plek om te kijken wanneer een URL stilletjes te lang is geworden.

Als een link die vroeger werkte plotseling niet meer werkt, voer dan dezelfde trace uit die je voor elke dode link zou gebruiken: korte link werkt niet doorloopt hoe je de bestemming direct controleert, en dat is precies hoe je een URL zou betrappen die parameter voor parameter over de limiet van een server is gegroeid.

Wat te doen wanneer een URL te lang is

Twee oplossingen werken echt, en het zijn dezelfde twee, ongeacht welke limiet je hebt geraakt.

De eerste is de URL verkorten. Een korte link is een wijzer met vaste lengte - de slug blijft even lang, ongeacht hoeveel de bestemming of de trackingparameters ervan groeien, omdat dat allemaal server-side leeft en bij elke klik wordt opgezocht in plaats van in de link zelf te worden meegedragen. Dat lost het dichtheidsprobleem van de QR-code, het segmentprobleem van sms en het spreadsheetprobleem in een beweging op, aangezien alle drie zich bekommeren om het aantal tekens van de link, niet om de lengte van waar hij uiteindelijk naartoe wijst.

De tweede is om state volledig uit de querystring te halen. Als wat je URL lang maakt sessiedata is, een blob met winkelwageninhoud, of een lange lijst filters in plaats van echte trackingparameters, hoort die data meestal server-side achter een ondoorzichtige ID, niet uitgeschreven in de adresbalk. Een URL die luidt /checkout?session=a1b2c3d4 veroudert beter dan een die luidt /checkout?items=... met elke SKU en hoeveelheid volledig uitgeschreven, en hij omzeilt in een klap elke limiet uit dit artikel, omdat er niets langs meer over is om te meten.

Beide oplossingen wijzen dezelfde kant op: behandel de lengte van een URL als een ontwerpbeslissing, niet als een toevalligheid van hoeveel parameters zich toevallig hebben opgestapeld.

Lees de cornerstone-serie

Dit artikel valt onder de engineering-cluster. Voor wat er gebeurt aan de andere kant van een korte link, behandelt hoe URL-verkorters werken de lookup zelf, en behandelt soorten URL-redirects de statuscodes die erbij komen kijken zodra de bestemming is gevonden.

Gerelateerd op de blog

• URL-encoding uitgelegd: welke tekens je moet escapen
• UTM-parameters uitgelegd, met een naamgevingsschema dat blijft werken
• Hoe groot moet een QR-code zijn? Regels voor formaat en afstand
• URL-verkorter voor sms-marketing die providers vertrouwen
• Korte link werkt niet? Diagnosticeer het met een commando