When Linking to a Text Fragment, :~:text= is used as part of the URL to identify text to highlight:


When using a link like this on SE in posts using Markdown, the tilde, ~, is escaped to %7E. This causes Chromium to not recognize the :~:text= and text highlighting to fail. Today, I tested this on meta.stackexchange.com and had the same problem. Such links do work in comments and if the link is added as an HTML <a href=""> tag.

On Stack Exchange, text highlighting only works in posts when the link is created with HTML anchor tags (<a>), with the link specified in the href attribute.

Link Type Typed Text Link Works? Example
HTML <a href="example.com#:~:text=test">text</a> Yes
How do I search tags?
Markdown [text][1]
How do I search tags?

Markdown links are much easier to interpret when composing a post, but tildes are escaped when using them, which causes the highlight feature to fail.

In a previous question, Link with underscore does not work, a problem with underscores (_) being escaped to %5F was noted and has since been resolved.

Could a change be made to prevent escaping the tilde character (~) in Markdown links?

* - "Text Fragments" is a, currently, non-standard feature which is implemented in Chromium (e.g. Google Chrome, etc.) and Safari. It was proposed a few years ago (2019/2020), but is not on a standards track. It is, however, slowly being implemented in other browsers, so something will likely end up being added to the standards. For Firefox, while Mozilla is generally positive on it, there's nobody working on implementing it at this time.

  • So, to clarify, links composed as HTML anchor elements (<a>) keep the ~ character unescaped, but Markdown footnote links do not. Does this happen with Markdown inline links ([link text](url)) as well?
    – zcoop98
    Sep 22, 2021 at 19:04
  • @zcoop98 - Didn't try it. I don't normally use that form.
    – Rick Smith
    Sep 22, 2021 at 19:07
  • 4
    It appears it's the same, inline links also escape the ~, breaking highlighting.
    – zcoop98
    Sep 22, 2021 at 19:14
  • See also: stackoverflow.com/a/62162093
    – Rob
    Sep 22, 2021 at 19:25
  • 1
    @Rick Just made a pretty substantial edit to try and improve the overall clarity of what's going on, and highlight specifically why the link isn't working. If you feel its too drastic, or strayed too far, please feel free to rollback or edit it to your linking.
    – zcoop98
    Sep 22, 2021 at 19:51
  • I just spent some time figuring out why I can’t link to MDN docs with the URL https://developer.mozilla.org/en-US/docs/Web/CSS/--*. Whenever I click on my link, I get a 404 page on the URL https://developer.mozilla.org/en-US/docs/Web/CSS/--%252A. I only noticed this because I have a userscript that shortens links in comments. My script removes https: so it becomes a protocol-relative URL — this works fine. But my script also removes /en-US — this works in virtually all circumstances, but it causes the MDN server to redirect to …/en-US/…. This redirect is usually not problematic. Mar 6, 2022 at 23:52
  • Now, when SE converts my Markdown to HTML, it encodes the * as %2A. This is the same encoding as in this question — the one that should be prevented. Inspecting the link and doing .getAttribute("href") literally includes the %2A. Other Markdown–HTML converters, e.g. GitHub’s, don’t do this. .getAttribute("href") literally preserves the *. MDN’s redirect, when adding the /en-US, unfortunately sees …/--%2A and replaces it with s/%/%25/g, resulting in …/%252A. Yes, it’s broken, but it’s an example of the fact that URLs must not be assumed to be equivalent to escaped URLs! Mar 6, 2022 at 23:52
  • Note: Scroll-To-Text Fragment is non-standard, but something like it will, probably, eventually be standard. It's primarily supported by Chrome and browsers based on Chromium, but not other browsers. So, while I agree that this should be supported in SE's backend conversion of Markdown➞HTML, it's debatable what level of priority this should be for SE.
    – Makyen
    Aug 3, 2022 at 17:37
  • 2
    I'd note that the issue could/should be considered a bug in Chromium, in that it's not recognizing :%7E:text= as a valid alternate for :~:text=. Even the IETF RFC3986 section 2.4 says 'For example, the octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by "~" without changing its interpretation.' So, technically, this looks like a bug in Chromium's implementation. At a minimum, people will likely point fingers back and forth as to responsibility.
    – Makyen
    Aug 3, 2022 at 17:38
  • There were some problems with tildes elsewhere in the URL too.
    – Laurel
    Dec 27, 2022 at 21:05


You must log in to answer this question.

Browse other questions tagged .