Es gibt keine maximale URL-Länge. RFC 3986, der Standard, der die URI-Syntax definiert, legt nie eine fest - er beschreibt, welche Zeichen erlaubt sind und wie eine URL zusammengesetzt wird, und hört dort auf. Worauf Sie tatsächlich stoßen, ist eine Kette separater, voneinander unabhängiger Limits: die Adressleiste Ihres Browsers, der Webserver auf der anderen Seite, der Proxy dazwischen, der E-Mail-Client, in dem jemand Ihren Link öffnet, oder der QR-Code, den Sie gerade drucken wollen. Jedes davon setzt seine eigene Obergrenze durch, und die reale maximale Länge einer URL ist die jeweils niedrigste dieser Grenzen. Verschicken Sie eine URL mit 3.000 Zeichen, und sie wird in Chrome vielleicht einwandfrei angezeigt, von einem Server mit Standardeinstellungen zurückgewiesen und kommt in Outlook über vier Zeilen umgebrochen an. Nichts davon ist ein Bug. Es ist die praktische Konsequenz eines Standards, der zu dieser Frage bewusst geschwiegen hat.
Daraus ergeben sich vier Themen: was der Standard sagt und was nicht, woher die berühmte Zahl von 2.083 Zeichen stammt und warum sie noch in Checklisten auftaucht, Jahre nachdem sie aufgehört hat, eine Rolle zu spielen, die Limits, die tatsächlich zuschlagen, sobald ein Link den Browser verlässt, und was zu tun ist, wenn eine URL zu lang geworden ist. Was ein Shortener mit all dem auf der Leitung macht, behandelt wie URL-Shortener funktionieren.
Was RFC 3986 tatsächlich über die URL-Länge sagt
RFC 3986 definiert die generische Syntax für URIs - Schema, Autorität, Pfad, Query, Fragment - und schweigt sich darüber aus, wie lang jeder dieser Teile werden darf. Nicht aus Versehen; bewusst. Die Grammatik in Abschnitt 3 baut eine URI aus einer kleinen Menge von Produktionsregeln auf, und nichts in diesen Regeln begrenzt, wie oft eine Regel wiederholt werden darf. Ein Pfadsegment kann, was die Syntax angeht, ein Zeichen lang sein oder hunderttausend. Lange URLs sind vollkommen legale URLs.
Das einzige Limit, das die RFC tatsächlich auferlegt, ist indirekt: Die Authority-Komponente einer URL enthält einen Hostnamen, und DNS begrenzt einen vollqualifizierten Hostnamen deutlich unter dem, was die URI-Grammatik erlaubt - Chromiums technische Dokumentation setzt diese Obergrenze bei insgesamt 253 Zeichen an, 63 pro Label. Pfad, Query-String und Fragment tragen an keiner Stelle im Standard eine solche Einschränkung.
Das ist die ganze Geschichte von der Spec-Seite aus. Das URL-Zeichenlimit, an das Sie in der Praxis tatsächlich stoßen, kommt von der Software, die die URL liest, nie vom URL-Format selbst.
Woher die 2.083 stammt, und was Browser heute tun
Wenn Sie irgendwo eine Richtlinie zur URL-Länge gesehen haben, nannte sie 2.083 Zeichen. Diese Zahl ist real, gehört aber zu einem Browser, einer Ära und einem Code-Pfad. Die WinINET-Netzwerkbibliothek des Internet Explorer definierte INTERNET_MAX_URL_LENGTH als 2083 Zeichen, und Microsofts eigener technischer Beitrag zu diesem Limit hält fest, dass die Adressleiste selbst ein Zeichen niedriger, bei 2047, begrenzt war. Diese Obergrenze prägte über ein Jahrzehnt lang einen riesigen Teil des Web-Traffics, sodass sie zur Zahl wurde, auf die alle hin entwickelten, und die Gewohnheit überlebte den Browser, den sie beschreibt.
Moderne Browser funktionieren nicht so. Chromes Dokumentation nennt ein internes Limit von 2 Megabyte, das Probleme bei der Interprozesskommunikation verhindern soll und nicht ein UI-Feld schützt, während eine deutlich kleinere Konstante, rund 32 Kilobyte auf dem Desktop, begrenzt, was die Omnibox tatsächlich anzeigt. Firefox und Safari sind ähnlich großzügig - keiner von beiden verschluckt sich an einer URL, die auch nur annähernd so lang ist wie das, was Sie von Hand bauen würden. Ich habe noch nie ein reales Produktionsproblem debuggt, das dadurch entstand, dass ein moderner Browser eine lange URL zurückwies. Jeder Long-URL-Bug, den ich je verfolgt habe, begann erst hinter dem Browser.
Die Limits aus der Praxis, die tatsächlich zuschlagen
Reihen Sie auf, wo eine URL tatsächlich überall durchläuft, und ein Muster zeigt sich schnell: Das strengste Limit sitzt selten im Browser.
- Die Server-Request-Zeile liest die URL als Teil der ersten Zeile einer HTTP-Anfrage, und diese Zeile hat ihren eigenen Puffer. Sprengen Sie ihn, parst der Server Ihre Route gar nicht erst - er weist die Verbindung zurück, bevor Ihr Anwendungscode überhaupt läuft.
- E-Mail-Clients gehen mit einem Überlauf unterschiedlich um. Outlook bricht eine lange Klartext-URL über mehrere Zeilen um, statt sie abzuschneiden, was hässlich, aber weiterhin klickbar ist; manche Webmail-Clients und Weiterleitungs-Gateways sind weniger nachsichtig und kappen den Link rigoros.
- Ein Link in einer Textnachricht konkurriert mit dem Nachrichtentext um dasselbe Zeichenbudget, und Links im SMS-Marketing leben innerhalb eines 160-Zeichen-Segments - eine lange URL allein kann eine Ein-Segment-SMS auf zwei Segmente treiben, die Mobilfunkanbieter unterschiedlich abrechnen und filtern.
- Ein QR-Code schneidet eine lange URL nicht ab; er wird einfach dichter. Wie groß ein QR-Code sein muss hängt direkt davon ab, wie viel Sie ihn zu encodieren bitten, und eine mit Tracking-Parametern überladene URL kann einen Code um eine Version oder zwei nach oben treiben und dabei die Distanz verkleinern, aus der er noch scannt.
- Hyperlink-Funktionen in Tabellenkalkulationen setzen ein eigenes hartes Zeichenlimit für das Link-Argument durch, deutlich unter einer typischen mit Tags versehenen URL, und ein Link, der es überschreitet, versagt lautlos - die Zelle wird einwandfrei angezeigt, der Link selbst funktioniert nicht.
- Werbeplattformen begrenzen das Ziel-URL-Feld auf eine selbst gewählte feste Länge, eine Plattformregel und keine technische, und ein Kampagnenmanager merkt es erst, wenn der Speichern-Button ablehnt, was ein Browser klaglos öffnen würde.
Keines dieser Limits kommuniziert mit den anderen. Eine URL kann die Request-Zeile Ihres Servers problemlos passieren und trotzdem drei Abteilungen später in einer Tabelle sterben.
Request-Zeilen-Limits bei Server und Proxy
Der Server-Fall verdient einen eigenen Blick, denn er ist der einzige, der einen echten Fehlercode statt eines kosmetischen Glitches produziert. 414 Request-URI Too Long ist die Antwort, die ein Server sendet, wenn er sich weigert, eine Anfrage zu verarbeiten, weil die URI länger ist, als er zu interpretieren bereit ist - ein URL-Größenlimit, das Hop für Hop durchgesetzt wird, von welcher Software auch immer die Request-Zeile gerade liest.
Jeder Server und Proxy in der Kette setzt seine eigene Version davon durch. Apaches LimitRequestLine-Direktive liegt standardmäßig bei 8.190 Byte für die gesamte Request-Zeile, was Methode und Protokollversion einschließt, nicht nur die URL selbst. nginx liest Request-Header in einen festen Puffer ein, der von large_client_header_buffers gesteuert wird, standardmäßig 8 Kilobyte, und eine Request-Zeile, die nicht hineinpasst, bekommt einen 414, bevor Ihre Route überhaupt gematcht wird. Load Balancer und CDNs, die einem von beiden vorgeschaltet sind, wenden oft ein drittes, separates Limit an, sodass eine URL die Einstellung Ihres Origin-Servers problemlos passieren und trotzdem einen Hop früher zurückgewiesen werden kann.
Wenn Sie nicht jeden Hop kontrollieren - und ab einer bestimmten Unternehmensgröße tut das niemand -, ist der sichere Weg, für den strengsten gemeinsamen Standardwert zu planen statt für den großzügigsten, den Sie in einer Konfigurationsdatei gefunden haben.
Die Redirect-Schicht selbst zu bauen, statt Request-Parsing von Hand zu basteln, ist hier die unspektakuläre Lösung. Elidos API akzeptiert ein Ziel jeder vernünftigen Länge und liefert dafür einen Kurzlink zurück, der nie seine Größe ändert, sodass die Request-Zeilen-Obergrenze eines Servers zu etwas wird, das Sie einmal am Edge konfigurieren, statt zu etwas, das jede Integration selbst handhaben muss.
Wie Sie die reale Länge einer URL messen, bevor Sie sie verschicken
Die Zeichenzahl ist die gesamte Messung, und es lohnt sich, sie zu prüfen, bevor eine URL in eine Kampagne geht, statt erst, nachdem ein Bounce-Report reinkommt.
printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c
Das liefert Ihnen die Byte-Länge der URL genau so, wie sie geschrieben ist. Zwei Dinge erschweren das. Erstens kosten percent-encodierte Zeichen mehr, als sie aussehen: Ein Buchstabe mit Akzent oder ein Emoji innerhalb eines Query-Werts kann sich beim Encoding auf sechs Zeichen oder mehr aufblähen, messen Sie die URL also nach dem Encoding, nicht davor. Zweitens sind UTM-Parameter meist der am schnellsten wachsende Teil einer URL - eine Handvoll Campaign-, Source-, Medium- und Content-Tags kann mehrere hundert Zeichen zu einem ursprünglich kurzen Pfad hinzufügen, und sie sind der erste Ort, an dem Sie nachsehen sollten, wenn eine URL lautlos zu lang geworden ist.
Wenn ein Link, der bisher funktioniert hat, plötzlich nicht mehr geht, führen Sie dieselbe Fehlersuche durch wie bei jedem toten Link: Kurzlink funktioniert nicht geht Schritt für Schritt durch, wie man das Ziel direkt prüft, und genau so würden Sie eine URL erwischen, die Parameter für Parameter über das Limit eines Servers hinausgewachsen ist.
Was tun, wenn eine URL zu lang ist
Zwei Lösungen funktionieren tatsächlich, und es sind immer dieselben zwei, egal welches Limit Sie ausgelöst haben.
Die erste ist, die URL zu kürzen. Ein Kurzlink ist ein Zeiger fester Länge - der Slug bleibt gleich lang, egal wie sehr das Ziel oder seine Tracking-Parameter wachsen, weil das alles serverseitig lebt und bei jedem Klick nachgeschlagen wird, statt im Link selbst mitgeführt zu werden. Das löst das Dichteproblem beim QR-Code, das Segmentproblem bei SMS und das Tabellenproblem in einem Zug, denn alle drei kümmert die Zeichenzahl des Links, nicht die Länge dessen, wohin er letztlich zeigt.
Die zweite ist, Zustand vollständig aus dem Query-String herauszunehmen. Wenn Ihre URL nicht wegen echter Tracking-Parameter lang wird, sondern wegen Sessiondaten, eines Warenkorb-Blobs oder einer langen Filterliste, gehören diese Daten meist serverseitig hinter eine opake ID und nicht ausformuliert in die Adressleiste. Eine URL, die /checkout?session=a1b2c3d4 lautet, altert besser als eine, die /checkout?items=... lautet mit jeder SKU und Menge ausgeschrieben, und sie umgeht mit einem Schlag jedes Limit in diesem Beitrag, weil nichts Langes mehr übrig bleibt, das man messen müsste.
Beide Lösungen zeigen in dieselbe Richtung: Behandeln Sie die Länge einer URL als Design-Entscheidung, nicht als Zufallsprodukt davon, wie viele Parameter sich zufällig auf ihr angesammelt haben.
Die Cornerstone-Serie lesen
Dieser Beitrag gehört zum Engineering-Cluster. Was am anderen Ende eines Kurzlinks passiert, behandelt wie URL-Shortener funktionieren mit dem Lookup selbst, und Arten von URL-Redirects behandelt die Statuscodes, sobald das Ziel gefunden ist.
Verwandte Beiträge im Blog
Häufig gestellte Fragen
Wie lang darf eine URL maximal sein?
Der Web-Standard selbst definiert keine. RFC 3986 legt die Syntax einer URL fest, begrenzt aber nie ihre Länge, sodass die reale Obergrenze das System in der Kette ist, das das strengste Limit durchsetzt: ein Browser, ein Server, ein E-Mail-Client oder ein QR-Code. Eine URL unter etwa 2.000 Zeichen zu halten, erfüllt fast alle diese Systeme auf einmal, weshalb diese Zahl immer wieder als sicherer Zielwert auftaucht, obwohl kein einzelner Standard sie verlangt.
Warum heißt es, eine URL dürfe nur 2.083 Zeichen lang sein?
Diese Zahl stammt aus der WinINET-Netzwerkbibliothek des Internet Explorer, die INTERNET_MAX_URL_LENGTH auf 2083 Zeichen festlegte, während die Adressleiste des Browsers selbst ein Zeichen niedriger bei 2047 lag. Sie prägte jahrelang einen großen Teil des Web-Traffics, wurde dadurch zur stillschweigenden sicheren Annahme, und die Gewohnheit, sie zu zitieren, überlebte den Browser, den sie beschrieb.
Wie lang darf eine URL in Chrome und anderen modernen Browsern sein?
Chromes eigene Dokumentation nennt ein internes Limit von 2 Megabyte, das Probleme bei der Interprozesskommunikation verhindern soll und nicht die Adressleiste schützt, während eine separate Konstante begrenzt, was die Omnibox tatsächlich anzeigt, auf Desktop-Plattformen rund 32 Kilobyte. Firefox und Safari sind ähnlich großzügig. In der Praxis ist kein aktueller Browser das Limit, an das Sie zuerst stoßen.
Was passiert, wenn eine URL zu lang ist?
Der Fehler hängt vollständig davon ab, welches System sie zurückgewiesen hat. Ein Server oder Proxy liefert typischerweise eine 414-Request-URI-Too-Long-Antwort und führt Ihren Anwendungscode gar nicht erst aus; ein E-Mail-Client bricht den Link über mehrere Zeilen um oder schneidet ihn ab; ein QR-Code wird einfach dichter und aus der Distanz schwerer scannbar; eine Tabellenzelle kann einwandfrei angezeigt werden, während der zugrunde liegende Link lautlos aufhört zu funktionieren.
Wie lang sollte eine URL für SEO sein?
Die Länge allein ist kein Ranking-Faktor, aber eine URL, die mit unnötigen Parametern überladen ist, ist oft ein Symptom für etwas, das Suchmaschinen tatsächlich interessiert, etwa Duplicate Content oder eine unklare Seitenstruktur. Praktisch vermeidet es die oben genannten Kompatibilitätsprobleme, URLs deutlich unter 2.000 Zeichen zu halten, und einen kurzen, aussagekräftigen Pfad zu wählen, ist eher eine Usability- als eine SEO-Entscheidung.
Wie kann ich prüfen, wie lang eine URL ist?
Zählen Sie die Zeichen nach dem Encoding, nicht davor, denn alles außerhalb von reinem ASCII wird beim Percent-Encoding länger. Ein einzeiliger Terminalbefehl, printf '%s' "ihre-url" | wc -c, liefert Ihnen die exakte Byte-Länge, die Sie gleich verschicken, und genau diese Zahl sieht auch Ihr Server, E-Mail-Client oder QR-Code-Generator.
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Kostenlos, keine Anmeldung erforderlich · 2 pro Tag