We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.
URLs (Links) do not work in my PDFs (from Word Documents), because # ist replaced by %23, which results to an Error 404 in Browsers. Is there a workaround for this bug in Adobe Acrobat XI Standard?
Is this happening in your macOS even if you've updated to version 2020.009.20067 of Acrobat?
The issue was addressed in this update. But if you have updated to the latest version and you still experience the issue on mac computers, the bug seems to be only related to using the weblink plug-in tool.
At the time that this bytly answer was posted it seems that no one took the time to look deeper before giving in to third-party commercial solution.
So bytly.com is not the correct answer when in fact the issue was not a bug that render useless the entire Acrobat software. Just the weblink creation tool in Acrobat was broken. Moreover, not all versions of Acrobat were manifesting this issue.
However if you look at the release notes It looks like the fix only resolves the issue in Windows.:
If you missed reading this entire thread, below is what I posted earlier to address what actually works in Acrobat.
+++++THIS IS MY OLD REPLY
When you used this weblink tool it generates simple URLs out of the text string that you input but it fails to treat this field as an annotation. That is why you can't work around it.
If it was treated as an annotation you would be able to manually edit its tag propperties and even its container attributes.
To work around this, don't use the weblink plug-in to generate URI actions. Instead, follow the recommendations I posted for another user here:
var numWeblinks = this.addWeblinks(); console.println("There were " + numWeblinks + " instances of text that looked like a web address," +" and converted as such.");
Using the methods that I described in the bullets and notes above work, and more importantly, you will be able to see those hyperlinks treated as annotations in Acrobat too.
Last thoughts, Bytly.com is not the appropriate workaround nor the solution to this problem. Hyperlinks that are created in Adobe Acrobat Pro from a text string work perfectly fine and the encoding and decoding from text string to UTF-8 also works perfectly.
Just make sure not to continue to use the Weblink plug-in and let Adobe look into this and fix it.
The only thing that works for me is the bitly. I have the latest version and even copy/pasted in a text editor first, but it still doesn't work. I am adding the url as a link box over embedded text and an image on the pdf. It worked perfectly fine on Acrobat 9 until I updated to this DC version.
Are you saying that you tried every suggestion in the bullets that I posted above?
When you say bitly is the only thing that works, did you actually took the time to read through the long verbage that I posted and try each one of the methods?
I just said in my old thread that the method that you're using won't work.
You may need to be more specific about everything you're not saying here that you already tried.
I did a lot of research and testing on this and I'm not going to give up so easily just because an Apple user says that bitly is the solution.
I am used to not getting some of my factual answers marked as correct solutions anyway.
I think I've wasted my time here with another stubborn (or real dumb) Apple user, who is gonna fight till the end saying that bitly is the solution.
In the end you'll going to even say that you were able to figure it out on your own, with no help, and mark your own answer as correct solution.
I did follow steps you offered above, but I don't have time to be a software developer for an action I can simply do with adding a bitly link. The url I add in DC works and doesn't work using a # in the middle of the address. I've added links for years using Acrobat without an issue using a # and now there is. Thank you for your time on this. Much appreciated.
Oh, I found a step-by-step workaround as I know the bitly was a temporary fix and not ideal.
The URL should now launch correctly.
In addition to the update Adobe sent, this works properly if you have an older version of Acrobat (I'm using Acrobat X Pro, and it works there)
I created an e-book in Pages, Mac, and exported it to PDF. A signup link in the e-book: www.domain.com/page-title/#signup however unfortunately in the exporting process converted to www.domain.com/page-title/%23signup in the PDF, causing a 404 page. Since the e-book already had been distributed, I had to solve the 404 error the link caused.
After trying many code lines, found on different websites, the final solution to my problem was editing the .htaccess file on my server like this:
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / </IfModule> # END WordPress
RewriteRule ^([\w-]+)/#(\w+)$ $1/#$2 [R,L,NE,NC]
So the .htaccess file reads:
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^([\w-]+)/#(\w+)$ $1/#$2 [R,L,NE,NC] </IfModule> # END WordPress
(and some other lines for other purposes in my case.)
Regarding the creation of the PDF: The next time that I will publish a PDF e-book, I will edit the PDF – which I created from the Pages files – in Adobe Acrobat XI regarding the links whose hashtags "#" have been converted to "%23". Links edited in Acrobat containing a hashtag will work. And then distribute it. 🙂
Thank you for sharing that feedback... Interesting!
I'm getting this problem in Mac OS Catalina 10.15.7 on InDesign 2021 (16.1) when exporting an interactive PDF.
The weird bit is that it worked today, then stopped working and just kept changing # to %23. If I open the PDF in Acrobat DC it links correctly with the # symbol. If I open the same PDF in Preview, the link shows %23 even if I have edited and re-saved it using Acrobat DC. All of my Adobe software is up to date and my mac is on the latest version of Catalina - intentionally not upgrading to BigSur just yet.
I think I read before in these forumms not to use Preview, it will mess up the PDF... but I may be wrong and completely uninformed about why some users report issues with Preview.