# Link previews remove fragment identifiers from URLs
**URL:** https://forum.torproject.org/t/link-previews-remove-fragment-identifiers-from-urls/1916
**Category:** Forum Feedback
**Created:** [January 27, 2022, 5:03pm UTC](https://forum.torproject.org/t/link-previews-remove-fragment-identifiers-from-urls/1916 "2022-01-27T17:03:41Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@dcf](https://forum.torproject.org/u/dcf)
#### Post date: [January 27, 2022, 5:03pm UTC](https://forum.torproject.org/t/link-previews-remove-fragment-identifiers-from-urls/1916/1 "2022-01-27T17:03:41Z")
See this post, and the mailing list post it originates from:
- [https://forum.torproject.org/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-single-bridge/1483/19](https://forum.torproject.org/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-single-bridge/1483/19)
- [https://lists.torproject.org/pipermail/tor-relays/2022-January/020270.html](https://lists.torproject.org/pipermail/tor-relays/2022-January/020270.html)
I tried to link to a specific comment in a GitLab issue, using a URL with a fragment identifier (`#note_2772684`). But the link preview changes/canonicalizes the link, losing the fragment identifier.
The URL I posted was:
```plaintext
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40095#note_2772684
```
But the link preview changes the URL to
```plaintext
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095
```
Which looks like this, linking to the top of the issue, not the comment of 2022-01-26 I wanted:
> **[Add load balancing to bridge (#40095) · Issues · The Tor Project /...](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095)**
>
> We rehearsed a load-balanced bridge installation in
My guess is that the forum is taking the `og:url` metadata property from the [Open Graph](https://en.wikipedia.org/wiki/Facebook_Platform#Open_Graph_protocol) tags on the page. The linked-to page has:
```html
```
Ideally, the forum would retain URL fragment identifiers even after canonicalizing the URL, in the same way the browsers keep the fragment after following redirects.
Notice how another URL in the post, [https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties), does not have Open Graph tags, does not get a link preview, and keeps its fragment identifier.
---
### Author:  [@dcf](https://forum.torproject.org/u/dcf)
#### Post date: [January 27, 2022, 5:54pm UTC](https://forum.torproject.org/t/link-previews-remove-fragment-identifiers-from-urls/1916/2 "2022-01-27T17:54:14Z")
It looks like Discourse/Oneboxer has a setting somewhere, `preserve_fragment_url_hosts`:
>
```ruby
def self.preserve_fragment_url_hosts
@preserve_fragment_url_hosts ||= ['http://github.com']
end
```
Possibly related:
> **[Oneboxing of sites with hash (#) in URL not working](https://meta.discourse.org/t/oneboxing-of-sites-with-hash-in-url-not-working/66804)**
>
> I’m pretty sure this used to onebox nicely with a highlighted line https://github.com/discourse/discourse-slack-official/blob/master/lib/discourse\_slack/slack.rb#L227 ...
`https://meta.discourse.org/t/why-instagram-link-onebox-like-this/138047/6`
> It seems that some Instagram pages have a canonical link with a different url that requires login. The code in the onebox library prefers the canonical url.