when adding webpages the % in the url is changed

When I add a new webpage to scrivener, the url is changed.
The % is replaced by %25.
medicinfo.info/%7Bd4914323-b … c472825%7D
is changed to
medicinfo.info/%257Bd4914323 … 72825%257D

How are you importing the webpage–dynamic browser, HTML, etc.–and where are you checking the address after import? I tried with a couple pages including the example address you gave but couldn’t reproduce this problem, so if you could give me specific steps, I’d appreciate it!

keep in mind the %25 (25 actually) is the correct URL representation of %

It sounds like how ever the URL is being entered it is being doubly encoded. You might try unencoding the URL and then entering it. If I remember correctly %7B is { and %7D is }

Yep, and that’s how this one displays if I link to it or import it from the website; otherwise, copying and pasting the given URL directly into the import dialog for dynamic browsers, it appears in the footer exactly as typed. In the other examples I tried though the URL still displays in the footer identically to the browser address bar, and the import works as expected, so I’m not sure where it’s enacting the change reported, even to “correct” an address.

More detail: not all existing characters and symbols are allowed to appear in a URL. Those that can’t be used are represented by a % followed by a 2-character hexadecimal value that indicates the disallowed character’s position in the standard character table. As Jaysen indicated, for instance, %7B stands for the impermissible character { and %7D stands for }. More information here and here.

So it looks like two things are happening: (1) the URL in question meant to represent {d4914323-b7f3-4d2c-a2ce-981b8c472825} as its last component. (2) For some reason, when hv1606 tries to add this into Scrivener the % signs that signal the hex code for the disallowed characters { and } are being interpreted as literal % signs, and are then represented by the appropriate hex code for a % sign, which is %25.

It still remains to be known what method hv1606 is using to import the URL, and why that is causing this misinterpretation.