URL 片段标识符 (Fragment Identifier，也称哈希) 是 URL 中「#」符号之后的部分。例如 "https://example.com/page#section2" 中的 "#section2" 就是片段标识符。浏览器会利用它自动滚动到页面中 id 属性匹配的元素位置。RFC 3986 第 3.5 节把片段定义为在已取得的资源之内间接指向某个次级资源，并说明其含义取决于该资源的媒体类型；HTML 中跳到 id 匹配的元素，正是这一解释的体现。想指向没有 id 的位置时，还可以在 #:~:text= 之后直接写出正文中的文字，即文本片段。不过它只在读者主动发起的跳转中生效；浏览器不支持，或者指定的文字在文档中找不到时，整个片段指令会被忽略，直接打开文档顶部。
片段标识符有一个重要特性：不会发送到服务器。当浏览器访问 "https://example.com/page#section2" 时，发送给服务器的请求只有 "https://example.com/page"，"#section2" 部分完全由浏览器端处理。
这一特性与短链接有关，但并不意味着片段会丢失。HTTP 规范 (RFC 9110 第 10.2.2 节) 规定，当重定向响应的 Location 值不含片段部分时，用户代理必须把该值视为继承了原始引用的片段来处理这次重定向。也就是说，打开 "https://example.com/abc#section2" 时，服务器收到的只有 "/abc"，但浏览器会把 "#section2" 带到跳转目标。真正不会被带过去的情形是跳转目标本身带有片段，此时以目标的片段为准。另一个要留意的点是，片段会从原来的链接直接传到另一个站点：同一规范第 17.11 节指出，这可能造成把一个站点的片段公开给另一个站点，并说明如果在片段里放了涉及个人的信息，就应当在跳转到其他站点时附上 (可以为空的) 片段部分，以阻止这种继承。此外，有些服务在保存原始 URL 时会把片段截掉，因此原始 URL 含有片段时，最可靠的做法是生成后实际打开确认。
在单页应用 (SPA) 中，片段标识符有时用于路由。例如 "https://app.example.com/#/dashboard"、"https://app.example.com/#/settings" 这样的哈希路由。这种写法的好处是不需要服务器端配置就能工作，但 Google 关于 URL 结构的指南说明，Google 搜索基本上不支持 URL 片段，并建议不要用片段来切换页面内容，而应改用 History API；它的 JavaScript SEO 文档也把通过片段加载内容的哈希式导航列为应当避免的写法。如果改用 History API 的路径路由 (/dashboard、/settings)，就需要在服务器端配置成无论直接打开其中哪个 URL 都返回该应用。
从 SEO 角度看，用片段的差异来切换内容的设计还是避开为好。如前所述，Google 明确表示搜索基本上不支持 URL 片段，因此不能指望 "example.com/page" 和 "example.com/page#section2" 被当作两个页面来对待。如果希望页面内的特定区域在搜索结果中单独出现，应把它设计成独立的 URL (子页面)，而不是使用片段标识符。