Summary

  • The # suffix is separated from the address used to retrieve a resource; the user agent interprets it against the returned representation.
  • From HTML's named anchors to text/plain line ranges, fragments let a reference author aim at something more precise than a document's front door.

Give someone a link to a long document and you have given them homework. Add # and a target, and you have given them a bookmark. The difference is small enough to live at the end of an address and large enough to change who controls the reader's first view. The server supplies the document; the writer of the link chooses the point of arrival; the browser joins the two.

The separation was already explicit in RFC 1808, published in June 1995. Its relative-URL parser sets aside the # and following fragment before it continues parsing the URL. The notation may sit in the same string as the address, but it has another job. HTML 2.0, specified in RFC 1866 later that year, gives the familiar use: #fragment can point to an anchor in the same document, then an A element with a matching NAME in an HTML representation. A browser could load a document and move the reader directly to the relevant place. A whole page arrived; a small portion gained the spotlight.

In an April 1997 W3C architecture note, Tim Berners-Lee described the handoff with unusual clarity. The server returns a representation, and the client hands the fragment to software that understands its media type. He observed that the server is not given that fragment in the HTTP exchange. The note also insists that the name “fragment” is misleading: what follows # can identify a part, a view or something else defined by the document type. A bookmark in a book was the easiest case, not the entire ambition.

RFC 3986, the 2005 URI syntax standard, turned that architecture into a general account of indirect reference. A fragment identifies a secondary resource in relation to a primary one. Its meaning comes from the media type of the representation, and the user agent handles it after separating it from the URI used for retrieval. The RFC makes a political point in technical clothing: client-side referencing lets an author point selectively inside existing material, rather than waiting for the publisher to offer a separate server address for every paragraph. The origin controls what it publishes. It does not write every bookmark that readers will share.

The idea outgrew HTML's named anchors. RFC 5147, published in 2008, specifies fragments for text/plain using character and line positions or ranges. A plain text file has no HTML element IDs to jump to, so the pointer can describe a span by position. That extension makes the design principle easier to see. The fragment is interpreted with the type of material in hand; it is not a universal command the server must execute.

The modern HTTP boundary remains legible in RFC 9110: the fragment is outside the target URI sent in an HTTP request. In everyday terms, the origin receives the request for the page. The browser works out the place or view that # names after the representation arrives. A link author can make a useful route through someone else's long document using the mechanisms that document type provides. When that point is stable, the reader arrives where the argument actually is.

This is why the tiny mark deserves more respect than its keyboard position suggests. It made a document address serve both delivery and selective reference without asking the server for a new endpoint each time. Rearrange a page and its old bookmarks may miss their targets; stable anchors keep references useful. The act of pointing belongs to anyone who can write a link. The web page has a front door. The reader is allowed to say which shelf they came to inspect.