A URL fragment (also called a fragment identifier or hash) is the part of a URL after the "#" symbol. For example, in "https://example.com/page#section2," "#section2" is the fragment. The browser uses it to automatically scroll to the element with a matching id attribute. Section 3.5 of RFC 3986 defines a fragment as identifying a secondary resource indirectly, within the resource that was retrieved, and notes that its meaning depends on the media type of that resource; jumping to the element whose id matches is what that means for HTML. To point at a passage that has no id, there is also the text fragment syntax, which spells out the wording itself after #:~:text=. It only takes effect on navigations the reader initiates, and if the browser does not support it or the wording is not found in the document, the whole fragment directive is ignored and the top of the document is opened instead.
A critical characteristic of fragments is that they are never sent to the server. When a browser accesses "https://example.com/page#section2," the request sent to the server is just "https://example.com/page" - the "#section2" part is processed entirely on the client side.
This behavior matters for shortened URLs, but it does not mean the fragment is lost. Section 10.2.2 of RFC 9110 states that when the Location value of a redirect response has no fragment component, a user agent must process the redirection as if that value inherited the fragment of the original reference. So opening https://example.com/abc#section2 sends only /abc to the server, yet the browser carries #section2 over to the destination. It is not carried over when the destination URL has a fragment of its own, which then takes precedence. A second point to watch is that the fragment travels from the original link to another site: section 17.11 of the same specification notes that this can disclose one site's fragment to another site, and says a site that puts personal information in fragments ought to include a (possibly empty) fragment component in redirects to other sites in order to block that inheritance. Separately, some services drop the fragment when they store the original URL, so if the original URL contains one, the reliable check is to open the generated link and see.
In SPAs (Single Page Applications), fragments are sometimes used for routing. URLs like "https://app.example.com/#/dashboard" and "https://app.example.com/#/settings" use hash routing to manage page state via fragments. That form has the convenience of working without any server configuration, but Google's guidance on URL structure says Google Search generally does not support URL fragments and advises using the History API instead of fragments to change the content of a page, and its JavaScript SEO documentation lists hash-based navigation that loads content through fragments as a practice to avoid. Moving to path-based routing with the History API (/dashboard, /settings) requires the server to be configured so that it returns the application whenever any of those URLs is opened directly.
From an SEO perspective, it is safer to avoid a design that swaps content according to the fragment. As noted above, Google states that Search generally does not support URL fragments, so "example.com/page" and "example.com/page#section2" cannot be expected to be treated as separate pages. If you want a specific section to stand on its own in search results, design it as a separate URL (subpage) rather than a fragment.