I am trying to use an \href linking to a web URL including an HTML anchor pointer. Hence I am using a hash sign (#) in the URL. For example to link the page https://github.com/latex3/hyperref#bug-reports.

Here is a minimal example:


\href{https://github.com/latex3/hyperref#bug-reports}{link with hash that doesn't work}

\href{https://en.wikibooks.org/wiki/LaTeX/Hyperlinks#Commands}{link with hash where it works}


The problem is that the hash sign gets replaced by the URL escape character %23 when the PDF is generated. If I click on the link in the PDF the browser will get the link in the following form:


But this leads to an 404-Error on GitHub.

If I replace the %23 with # in the address bar, the proper page can be loaded.

On other pages (for example wikibooks) links with URL-escaped # work (shown in the example above).

Is it possible to switch off url-escaping of the hash sign in links?

I am using pdfTeX 3.14159265-2.6-1.40.21 (TeX Live 2020) on MacOS Catalina.

  • Maybe try loading xurl?
    – Bernard
    Jul 29, 2020 at 14:31
  • I'm a bit confused. You've found that the wikibooks link works with # unescaped. Why not leave it unescaped in the github link? My understanding is that hyperref does some stuff behind the scenes so that you don't need to escape # in the first place. And in fact, with TeXLive 2020, both of your examples work fine, so it seems that you can choose whether to escape # or not.
    – Teepeemm
    Jul 29, 2020 at 14:41
  • 6
    are you on mac? some pdf viewer are broken there and misinterprete the hash. github.com/latex3/hyperref/issues/110. There is nothing what hyperref can do here, the viewer must be fixed. Jul 29, 2020 at 14:57
  • 1
    @Mico acrobat should be fine, the reported issues were with preview and safari. Jul 29, 2020 at 15:16
  • 3
    hyperref does some hard work to allow you not to escape the # and still work correctly, so in general I'd prefer the unescaped # over \# anyway. In my tests all viewers resolved both links from the MWE correctly (PDF compiled with pdfLaTeX on MikTeX, checked the links with TeXworks' built-in viewer, SumatraPDF, Adobe Reader and Firefox).
    – moewe
    Jul 29, 2020 at 15:17

3 Answers 3


As was layed out in the comments the problem here is not LaTeX and not the Browser but the pdf viewer. Some PDF viewers on MacOS seem to convert the hash sign in the PDF that is correctly inserted by LaTeX.

There is a table in this bug report showing which pdf viewers on MacOS create the problem:

Table of PDF viewers with hash problem

The bug seems to be on the side of Apple and was reported on 2 March this year. No fixes yet. I think the workaround for now is to use a different PDF viewer.

Also this question might be a duplicate of this question.

  • It also does not work in TeXShop.app's PDF viewer (v4.66) (macOS 10.15.7) as of 9 August 2021: the hash is converted to %23 so the link is broken.
    – jvriesem
    Aug 9, 2021 at 18:34

I do not have the reputation to comment on the earlier reply, but I want to point out that Google Docs also makes this error, when you select the menu option to download a document in PDF format. I used a URL shortener to get around the problem.

  • Welcome to TeX.SE!
    – Mensch
    Nov 14, 2021 at 23:29

I'd like to point out that something more complex is going on. @nnn is correct that some of OSX's viewers are broken.

Compiling their code with pdfTeX 3.141592653-2.6-1.40.24 on OSX 10.15.7 and opening with Preview 11.0, the first link fails with the # replaced with %23, however the second link works without issue. I see no difference between the two links and the usage of the #. Also note that 23 is the ASCII hexadecimal value for #. Something more complex must be going on.

To provide a useful answer the question, Google Chrome (v.99.0.4844.83) on OSX 10.15.7, will open these files correctly.

  • "Something more complex must be going on." Because on Wikibooks, the URL with %23 is redirected by the server to the URL with # (you can see in your browser that the address with %23 becomes, after a quick refresh by the browser the address with %). On Github, they don't redirect, and the page with %23 doesn't exist. Wikibooks (and Wikipedia) has a lot of redirections. For exemple the wrong en.wikipedia.org/wiki/infared (see the lowercase and the missing "r") is redirected to en.wikipedia.org/wiki/Infrared.
    – quark67
    Jan 7, 2023 at 12:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .