# ist replaced by %23 in URLs ==> Error 404

Hi @sdfkjhbf23 and all other who participated in this thread,

InDesign 2023 still has this bug when URLs of hyperlinks are tested within the Hyperlinks panel with InDesign's menu command "Go to Destination".

There is no issue when the pages are exported to PDF. The # in the URL is not substituted in this case with %23.

But users of InDesign should be able to test correct URLs from the Hyperlinks panel as soon as the "green light" indicates that InDesign sees no issue.

So I like to campaign for fixing the bug in InDesign.

Please vote in InDesign's UserVoice bug report section at:

# in URLs of Hyperlinks in Hyperlinks panel is substituted with %23 when opened in browser from panel
Uwe Laubender, June 9, 2023

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/46757833--in-urls-of-hyperlinks-in-hyperlinks-panel-is-sub

Thanks,

Uwe Laubender
( Adobe Community Expert )

I'm getting this problem in Mac OS Catalina 10.15.7 on InDesign 2021 (16.1) when exporting an interactive PDF.

Trying to include a hyperlink with anchor https://domain.com/page#name and I'm getting https://domain.com/page%23name.

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.

My case:

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

Adding:

RewriteRule ^([\w-]+)/#(\w+)$ $1/#$2 [R,L,NE,NC]

after

RewriteBase /

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. 🙂

I have the same issue on my Mac Pro Catalina. It's not a server issue, the "#" is replaced with a %23 and it takes you to a 404 web page on any browser or computer. This is a glitch I hope will be addressed. In the meantime, making a bitly link is a simple, but genius workaround.

THANK YOU ADOBE!!!

this issue has been fixed with the last update to version:

2020.009.20067

Hi everyone!

Today Adobe pushed out a new optional update that finally addresses this issue.

Apply this last update and see how your Acrobat behaves.

++++++COMPLETELY EDITED REPLY : TOO MANY TYPOS, BAD GRAMMAR, POORLY ORGANIZED CONTENT.

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.

Hi everybody!

I'm sorry to break the cheerful mood and be the actual party-pooper that is about to ruin the partially fructiferous pseudo-victory here.

I don't know how you're able to get over 18K views by suggesting a third-party solution in the Adobe community support forums.

I am 100% positive that if it was me who posted that link here, a lineup of MVP's and ACP's would've jump already to tell me that I can't do that, and 12 months later  I would still be wondering why does my answer was never marked as a correct solution.

This problem has nothing to do with a particular operating system platform; I confirmed that it happens using any version of MS Windows 7 through MS Windows 10.

So it is most likely that a bug was introduced via recent updates of Acrobat Pro DC or no-one has ever cared to look into this since 2012...

Anyway, according to another user that I was helping out yesterday, the problem doesn't manifest with Acrobat DC 2017.

The person had uninstalled Acrobat Pro DC as a "band-aid"  remedy (I quote).  Moreover, in an environment where a user has to  process thousands of documents with URL web links, bytly.com imposes a cap to a maximum limit of URLs that a user is able to fix using their service.

Here is my post to that person 3 hours ago before I posted in this thread: 

• https://community.adobe.com/t5/acrobat/replaced-by-23-when-creating-a-web-link/m-p/11155606?page=1#M258537

When you reach that limit you have to subscribe and pay; this is not a convenient solution for mass production of PDFs with weblinks. So, I am going to post here the real work around using very basic javascripting ( I am just learning JavaScript by the way).

If this problem is indeed a bug, when you use the Create Web Link wizard from the "Edit Tool" it seems as if something is not converting the hash or pund symbol appropriately to the corresponding Unicode symbol .

If that is the case it is likely that the symbol is not available in the current font or typeface that is currently used by the JavaScript editor or by the PDF document in general.

• NOTE: you also get this symbol by pressing the ALT key in your keyboard and typing the digits 3 and 5 on the numeric keypad, for example ( ALT+35).

So lets us take a look at the slides below:

• If you use the regular  Create Web Link wizard from the "Edit Tool"

• After you enter the URL with an page opening parameter this is what you get:

If you refer to a Unicode table, look for the ASCII punctuation and symbol symbol section for " # " (without the quotes" ) you will notice  U+0023 <<<---------- SEE THE RELATIONSHIP WITH THE %23 NOW???

See a lot more here:

• https://gist.github.com/ivandrofly/0fe20773bd712b303f78

• Unless I missed a Preference setting in Acrobat and until someone in Adobe can confirm if this is indeed a Unicode-related bug, I will safely assume that this  is related to the typeface used in the JavaScript editor (shown below in the next slide))

• However, When you try to change %23 back to a pund (#) sign and you highlight it and right-click on it, notice all of the interesting Unicode options that are available through this context menu.... See slide below and  ask yourselves Why is this here if this is NOT related to Unicode? 

• You can try yourself and see if messing with any of those resolve the issue. But I've spent about 6 hour or more researching and playing around with this.

As you can see, this problem has nothing to do with web servers, plug-ins, MS Office add-ins, browser add-ons, macros, Active X control in Windows, and what not.

This is most likely a bug like I've suggested earlier, and I am mostly inclined to think it is  between HTML and the JavaScript UTF types that are involved in this web linking process with Acrobat (but I may be wrong).

However, the best workaround at this time  is to use a javascript script instead of using the "Open a web link" method.

See the additional set of slides that I prepared and use this other method instead:

• Insert this line of code with your desired URL and its opening parameters using the exacct syntax in the example below:

// YOU CAN USE THIS EXAMPLE URL TO TEST AND SEE FOR YOURSELF IF IT WORKS

app.launchURL("http://www.adobe.com#page=3");

• Paste in the JavaScript editor as shown in the dialogue box to the right of the image below 

IT WORKS!

Since this bug still hasn't been fixed 5 years later, I found a solution to fix the incoming links on Apache web servers using mod_rewrite. Unfortunately this won't help if the PDF links to a website you don't own.

If you have access to an .htaccess file on your website you can try to detect the %23 and rewrite it to # automatically, rather than creating a manual redirect for every link. It's tricky because the %23 in the incoming REQUEST_URI is automatically decoded to # (so you have to actually look for # instead of %23), and then doubly tricky because the # in the destination url you redirect to is automatically re-encoded back to %23. You must use a noescape [NE] flag on your redirect to prevent the re-encoding and avoid an infinite loop. The good news is that Apache will only ever match %23, and never a literal # because the client-side anchor is stripped off before creating the server variables. So even though this pattern looks for #, you'll only find it for urls that contain %23 (such as the Adobe bug).

This worked for me but may be a little different for your needs (such as if done via VHOST instead of .htaccess):

RewriteEngine on
RewriteBase /

RewriteRule ^(.*)\#([^/]*)$ $1\#$2 [R=301,NE,L]

This pattern matches a link that ends with an anchor that has been converted into %23 (even though it matches a literal #) and redirects it to itself, while adding the noescape [NE] flag. This will not lead to an infinite loop of redirects, because once the # is written without %-encoding the anchor will no longer be visible to Apache after the first redirect. This should not affect any query strings because they are not matched by the RewriteRule pattern. If you want to automatically fix links containing both a query string and an anchor, you will need a more complicated solution involving a RewriteCond (because the %23 anchor then becomes part of the query string instead of part of the url path).

Disclaimer: If you're not familiar with mod_rewrite, be careful, it can easily break your website.

This is a bug that needs to be fixed. The bitly workaround is not acceptable for the reasons detailed by ArmandFrvr.