URL Fragment

A URL fragment is the part of a URL that follows the # symbol. It identifies a section inside a page rather than a separate resource, and the browser uses it to scroll straight to that section. The fragment is handled entirely by the browser and is never sent to the web server.
Where the Fragment Sits in a URL
The fragment always comes last. Every other component precedes it.
https://linkutm.com/blog/utm-guide?utm_source=newsletter#step-3
- Scheme:
https - Host:
linkutm.com - Path:
/blog/utm-guide - Query string:
?utm_source=newsletter - Fragment:
#step-3
RFC 3986 fixes that order. The fragment starts at the first # and runs to the end of the URL. A literal # inside any earlier component has to be percent-encoded as %23, or the browser reads it as the start of the fragment.
The value after # normally matches the id attribute of an element on the page:
<h2 id="step-3">Step 3: Tag Your Links</h2>
Matching is case sensitive. #Step-3 will not find id="step-3.
Why the Fragment Never Reaches the Server
Browsers strip the fragment before sending the HTTP request. RFC 3986 section 3.5 defines it as client-side data: the server returns the full document, then the browser finds the target and scrolls to it.
Three consequences follow:
- Server logs, server-side tagging, and CDN rules never see the fragment.
- The fragment is stripped from the
Refererheader regardless of referrer policy. - Only client-side JavaScript can read it, through
window.location.hash.
That last property has a security use. OAuth implicit flow returns access tokens in the fragment specifically so the token stays in the browser and never lands in a server access log.
Fragments also survive redirects. When a Location header carries no fragment of its own, browsers reapply the fragment from the original request to the destination URL. A short link ending in #pricing still lands on the destination page’s pricing section.
Types of URL Fragments
- Document anchors.
#pricingjumps to the element withid="pricing. By far the most common use. - Text fragments.
#:~:text=bounce%20ratescrolls to and highlights matching text with noidrequired. Chrome shipped it in version 80 (February 2020), Safari added it in 16.1, Firefox in 131. Google uses text fragments for its scroll-to-text links from search results. - Hash routes. Single-page apps use
#/dashboardto switch views without a server request. The older hashbang form (#!) served the same purpose. - Media and document fragments.
#t=30starts an audio or video file 30 seconds in.#page=4opens a PDF at page four. - State fragments. Apps park transient values after the
#(auth tokens, map coordinates, filter state) precisely because that data stays client-side.
Special case: #top and a bare # both scroll to the top of the document. The HTML specification defines that behavior, so no element with id="top is needed.
URL Fragments and SEO
Google drops everything after the # when it processes a URL. https://linkutm.com/pricing and https://linkutm.com/pricing#plans are one page and one index entry, so fragments cannot create duplicate content the way query parameters can. Ranking signals are never split across them.
Two practical implications:
- Hash routes are invisible to search. Content that exists only at
#/product/42has no crawlable URL of its own. Use the History API with real server-rendered paths instead. Google deprecated its AJAX crawling scheme, the#!workaround, in October 2015 and stopped supporting it in 2018. - Fragments still show up in results. Google builds jump-to links from a page’s heading anchors and displays them under the main result. Stable, descriptive
idvalues on H2 headings are worth keeping for that reason alone.
Fragments and Campaign Tracking
Order matters: tracking parameters go before the #, never after.
Correct:
https://linkutm.com/pricing?utm_source=newsletter&utm_medium=email#plans
Broken:
https://linkutm.com/pricing#plans?utm_source=newsletter&utm_medium=email
In the broken version, the entire string plans?utm_source=newsletter&utm_medium=email is the fragment. None of it reaches the server, and Google Analytics records the visit with no campaign attached. This is the most common way fragments quietly destroy attribution, and it usually happens when someone appends UTM tags to a link copied out of an on-page navigation menu.
One more tracking note. GA4 enhanced measurement fires a page_view on browser history events, so hash-route apps can log extra page views for what a visitor experiences as a single visit.
Common URL Fragment Mistakes
- Placing query parameters after the
#. This kills campaign tracking. - Leaving a literal
#unencoded inside a parameter value instead of writing%23. - Case mismatch between the fragment and the target
id. - Relying on hash routes for content that needs to rank.
- Expecting fragments to appear in server logs or server-side tagging.
- Assuming a fragment URL needs its own canonical tag. It does not.
To inspect one, run window.location.hash in the browser console for the current fragment, or open DevTools and check the Network tab, where the request URL appears without it.
Frequently Asked Questions
What is a URL fragment?
A URL fragment is everything after the # in a URL. It points to a location inside the page that has already loaded, most often an element whose id matches the fragment value. Browsers use it to scroll to that spot and never send it to the server. RFC 3986 defines it as the final component of a URL, after the scheme, host, path, and query string.
What does # mean in a URL?
The # marks the start of the fragment identifier. Everything to its right is an instruction for the browser rather than the server: scroll to this heading, open this app route, highlight this text. A URL has only one meaningful #. The first one begins the fragment, and any later ones count as part of its value.
What is the difference between a URL anchor and a fragment?
The fragment is the part of the URL after #. The anchor is the thing on the page it points at. The terms blurred because early HTML marked targets with <a name="section">, and people called the whole mechanism an anchor link. Modern HTML uses the id attribute on any element, so “fragment” describes the URL and “anchor” describes the destination.
Is a hash fragment in a URL sent to the server?
No. The browser removes the fragment before making the HTTP request, so it never appears in a server log, access record, or server-side tag. Only JavaScript running in the page can read it, through window.location.hash. That is exactly why OAuth implicit flow and similar patterns pass tokens in the fragment.
Do URL fragments affect SEO?
Barely. Google ignores the fragment when indexing, so a page and the same page with #section count as one URL with one set of ranking signals. The exception is content that exists only behind a hash route, which gives search engines nothing to crawl. Google retired the #! AJAX crawling scheme in 2015 for that reason.
Paste any tagged link into linkutm’s URL parser to see exactly where the query string ends and the fragment begins.