Ein Uniform Resource Locator (Abk. URL; für „einheitlicher Verorter für Ressourcen“) identifiziert und lokalisiert eine Ressource, beispielsweise eine Webseite, über die zu verwendende Zugriffsmethode (zum Beispiel das verwendete Netzwerkprotokoll wie HTTP oder FTP) und den Ort () der Ressource in Computernetzwerken. Der ursprüngliche Standard wurde im Dezember 1994 als RFC 1738 publiziert; er ist inzwischen durch die Veröffentlichung mehrerer anderer RFCs obsolet. Im Jahr 2023 waren folgende RFCs aktuell:

URLs sind eine Unterart der generellen Identifikationsbezeichnung mittels Uniform Resource Identifiern (URIs). Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufig synonym verwendet. Im allgemeinen Sprachgebrauch werden URLs auch als Internetadresse oder Webadresse bezeichnet,Duden – Deutsches Universalwörterbuch. 6. Auflage. wobei damit (der umgangssprachlich häufigen Gleichsetzung von Internet und WWW folgend) meist speziell URLs von Webseiten gemeint sind.

Aufbau Der grundsätzliche URL-Aufbau besteht aus einer die Zugriffsmethode festlegenden Schema-Bezeichnung (englisch scheme) und einem Schema-spezifischen Teil (scheme-specific part), die durch einen Doppelpunkt getrennt sind: <scheme>:<scheme-specific-part>

Schema (scheme) Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll. Ist meistens, aber nicht zwingend gleichlautend mit dem verwendeten Netzwerkprotokoll, über das die Ressource lokalisiert werden kann. Beispiele sind:

mit gleich lautendem Protokoll: http, https oder ftp mit anderem Protokoll: mailto (zum Schreiben einer E-Mail) oder file (zum Zugriff auf lokale Dateien).

Schema-spezifischer Teil (scheme-specific part) Je nach Schema sind unterschiedliche spezifische Angaben erforderlich und möglich. In den meisten Fällen beginnt er mit der Zeichenkette //, jedoch ist bei manchen Varianten auch lediglich der Doppelpunkt definiert. Die folgenden Beispiele beziehen sich auf das Hypertext Transfer Protocol (HTTP).

Benutzer und Kennwort (user, password) Falls benötigt, können Login-Informationen aus Benutzername (user) und Kennwort (password) mit übermittelt werden. Diese werden, voneinander durch Doppelpunkt getrennt, dem Host mit einem trennenden At-Zeichen (@) vorangestellt.

Auch wenn für dieses Beispiel das Protokoll HTTP gewählt wurde, ist die Angabe von Benutzername und Kennwort als Teil des URLs nicht Teil der HTTP-Spezifikation. Aktuelle Browser akzeptieren diese URL-Syntax zwar, fragen aber beim Benutzer nach, ob er sich wirklich mit den angegebenen Daten anmelden möchte. Der Internet Explorer 6 (ab Windows XP SP2) und neuere Versionen fallen hier aus dem Rahmen, indem sie diese URL-Syntax rundweg als fehlerhaft ablehnen. Mit einem Registry-Eintrag kann man sie zum gleichen Verhalten zwingen, wie es die Vorgänger bis Version 5.5 zeigen: Diese übernehmen die Anmeldedaten ungefragt und übergeben sie direkt an den Server.

Bei einigen anderen Protokollen, etwa FTP, ist die Angabe der Benutzerdaten in der gezeigten Form dagegen völlig korrekt und durch die Standards abgedeckt.

Host Die Host-Komponente wird in Form einer IPv4-Adresse in dezimaler Schreibweise durch Punkte getrennt, in Form einer IPv6-Adresse in hexadezimaler Schreibweise durch Doppelpunkte getrennt und in eckige Klammern gesetzt oder in Form eines FQDN notiert.

Port Die Angabe des Ports erlaubt die Ansteuerung eines TCP-Ports. Wird kein Port angegeben, so wird der Standard-Port des jeweiligen Protokolls verwendet – zum Beispiel bei HTTP 80, bei HTTPS 443 und bei FTP 21.

Pfad (Path) Der Pfad beschreibt eine bestimmte Ressource auf dem Server. Der Pfad kann auch leer sein; dieser leere Pfad kann optional durch einen Schrägstrich () ersetzt werden und ist zu diesem gleichbedeutend.

Klassischerweise (bei manchen Protokollen ist das auch so vorgeschrieben) entspricht der Pfad in der URL einem relativen Pfad unterhalb eines konfigurierbaren „Stammverzeichnisses“ auf dem Server. Die Interpretation des Pfades ist jedoch allein Sache des Servers und es ist durchaus üblich, dass Ressourcen über URL-Pfade angeboten werden, die keine Entsprechung im Dateisystem des Servers haben.

Traditionell stellt ein Pfad, der mit einem Slash abgeschlossen wird, ein Verzeichnis dar, während ein Pfad, der nicht mit einem Schrägstrich abgeschlossen ist, gewöhnlich eine „Datei“ kennzeichnet – also ein „Blatt“ am Ende eines Zweiges, während Verzeichnisse die möglichen Verzweigungen darstellen. Suchmaschinen behandeln beide Schreibweisen meist gleich. Da dies für Nutzer allerdings verwirrend sein kann, sollte unterschiedlicher Content auch in unterschiedlichen Pfaden abgelegt werden.

Die Interpretation (Datei oder Verzeichnis; Textdatei liefern oder Skript ausführen) bleibt dem Server überlassen. Ein typisches Beispiel für die Interpretationsfreiheit ist das Verhalten bei der Anforderung des Pfades / durch einen Client: Je nach Einstellung liefert der Server etwa den Inhalt einer namentlich ausgezeichneten Datei (wie /index.html, /README, /HEADER), ohne dass dies für den anfragenden Client ersichtlich ist. Genauso kann der Server allerdings – je nach Protokoll – auch explizit zu dieser Ressource weiterleiten oder eine Verzeichnisauflistung ausgeben.

Abfrage (Query)

Im Fall des HTTP kann nach dem eigentlichen Ressourcenzeiger – getrennt durch ein Fragezeichen – ein Query-String folgen. Damit können zusätzliche Informationen übertragen werden, die server- oder clientseitig weiterverarbeitet werden können.

Fragment

Nach einem Doppelkreuz kann ein Teil der Ressource referenziert werden, typischerweise ein Anker in einer HTML-Seite, zu dem nach dem Aufrufen der Seite automatisch hinuntergescrollt wird: Der URL http://example.com/dokument.html#absatz3 würde, in dem hier fiktiven Dokument, den Browser dazu veranlassen, zum Anfang des dritten Absatzes zu scrollen.

Der Fragmentbezeichner wird – im Gegensatz zum Query-String – nicht an den Server übertragen, sondern nur vom Client und etwaigen clientseitigen Skripten ausgewertet. Er kann also nicht dazu benutzt werden, z. B. nur Teile einer Ressource vom Server anzufragen.

Beispiele Für http(s): |--------------------------- Schema-spezifischer Teil -----------------------------|

https://maxmuster:[email protected]:8080/documentation/index.html?p1=A&p2=B#ressource \___/ \_______/ \____/ \_____________/ \__/\_______________________/ \_______/ \_______/

Schema¹ Benutzer Kennwort Host Port Pfad Query Fragment

¹ hier gleich Netzwerkprotokoll

Für mailto: mailto:[email protected] \____/ \_____________/

Schema² | E-Mail-Adresse gemäß RFC 5322

² hier kein Netzwerkprotokoll

Für news (in diesem Beispiel ist weder ein Netzwerkprotokoll noch eine Host-Adresse enthalten): news:alt.hypertext \__/ \___________/

Schema | Name der Newsgroup

Für file: file:///verzeichnis/unterverzeichnis/datei \__/ \_________________________________/

Schema | Pfad zu einer lokalen Datei im Dateisystem des Rechners, der den URL interpretiert Streng genommen hat das file-Schema die Form file://<host>/<path>, wobei aber der Host-Teil praktisch nicht verwendet wird, da das file-Schema mangels einer Möglichkeit, ein Netzwerkprotokoll für den Zugriff auf die Datei anzugeben, kaum sinnvoll über ein Netzwerk benutzt werden kann. File-URLs werden beispielsweise in der Programmiersprache Java verwendet, um auf diese Weise auf lokale Dateien zuzugreifen. Je nach Browser ist oftmals das Öffnen von file-Links nur nach spezieller clientseitiger Konfiguration oder unter Zuhilfenahme von Add-ons etc. möglich.File URI scheme #Browser behaviour in der englischsprachigen WikipediaFirefox beispielsweise blockiert aus Sicherheitsgründen seit 2012 alle lokalen Zugriffe mit file:, wenn das umgebende Dokument aus http:// stammt.

Konkrete Beispiele ftp://max:[email protected] … FTP mit Benutzer und Kennwort http://de.wikipedia.org … Website ohne Pfad (Aufruf der Startseite) http://de.wikipedia.org/wiki/Uniform_Resource_Locator … Website mit Pfad https://de.wikipedia.org … wie Aufruf der Website ohne Pfadangabe, allerdings mit dem verschlüsselten Hypertext Transfer Protocol Secure mailto:[email protected] … zum Schreiben einer E-Mail an die angegebene Mailadresse (öffnet den Standard-Mailclient mit einer neuen, leeren Nachricht, in der die TO-Adresse vorausgefüllt ist) news:alt.hypertext … Anzeige einer Usenet-Newsgruppe (generisch, ohne Angabe des Netzwerkprotokolls NNTP) nntp:alt.hypertext … Anzeige einer Usenet-Newsgruppe (mit Angabe des Netzwerkprotokolls NNTP) telnet:example.org … Start einer Telnet-Session file:///foo/bar.txt … Zugriff auf eine lokale Datei

Relative URLs Neben den bisher dargestellten absoluten oder vollständigen URLs gibt es auch relative URLs. Sie sind nur innerhalb eines Kontextes gültig, von dem sie Eigenschaften erben. Ihnen fehlt die Ortsangabe im World Wide Web oder einem echten Intranet-Web. Sie sind vor allem in der Gruppe http, https und ftp möglich, aber auch bei mailto. Das entspräche einer Telefonnummer ohne Vorwahl (des Landes, des Ortsnetzes).

+ Relative URLs für http, https, ftp Beginn Bedeutung Anmerkung Beispiel // Selbes Protokoll sinnvoll, um http: oder https: der momentanen Umgebung zu verwenden //example.com/pfad/zu/datei / Selbe Domäne (host:port), „Wurzelverzeichnis“ /pfad/zu/datei # Selbe Ressource Wirkung über Nebenwirkung # #fragment Selbe Ressource, Sprungmarke #knoten nichts Selbe Ressource ../ ein Pfad-Segment aufwärts Ein Server muss keine durch / gegliederte Pfad-Segmentierung unterstützen. /pfad/zur/../zur/datei ./relativer/pfad ./ sonstige Selbes Pfad-Segment

Relative URLs werden oft eingesetzt, um eine Gruppe zusammengehörender Ressourcen wahlweise in einem lokalen Dateisystem oder an unterschiedlichen Orten in verschiedenen Netzwerk-Domänen unverändert abzulegen und aufeinander zu verlinken. Im Übrigen ist die Interpretation des Identifikators (Zeichenkette zwischen host:port und #) jedem Server freigestellt – zwar handhabt es die weitaus überwiegende Anzahl der Server und jede Standard-Software wie oben angegeben, jedoch können / genau wie ? % & nach eigenen Regeln ausgewertet werden.

Bei mailto: wäre eine relative URL mailto:addr1 (ohne @)  möglich – sie gilt nur im lokalen Netzwerk.

Liste erlaubter Zeichen Reservierte Zeichen sind: Sonderzeichen : / ? # [ ] @ ! $ & ' ( ) * + , ; =

Nicht reservierte Zeichen sind: Buchstaben A–Z, a–z Ziffern 0–9 Sonderzeichen - . _ ~

In bestimmten Fällen ist außerdem das Leerzeichen ␣ (dieses alternativ auch mit + oder %) in Prozentkodierung (%20) darzustellen.

Sprachgebrauch Im deutschen Sprachgebrauch hat URL häufig den weiblichen Artikel, wird aber auch mit männlichem Artikel verwendet.Duden – Deutsches Universalwörterbuch, siehe auch duden.de Die Wahl des Genus hängt davon ab, ob es in Anlehnung an die deutsche Übersetzung die Adresse (feminin) gebildet wird oder mittels der Grammatikregel, dass Hauptwörter auf -or (hier Locator oder -identifikator) oder -er (-bezeichner, -lokalisierer, -anzeiger) im Deutschen stets maskulin sind.

URLs in Texten Anhang C von RFC 3986 empfiehlt, URIs (und damit auch URLs) in Texten

eigenständig auf einer Zeile, mit doppelten Anführungsstrichen "http://example.com/" oder mit spitzen Klammern <http://example.com/>

gegen den Kontext und vor allem gegen die Interpunktion des Satzes abzugrenzen.

URLs und Suchmaschinen