# Bug in link rendering?

It seems if URLs contain a $, this breaks markdown rendering. I'm guessing some interaction with the mathjax rendering. Example: [open termination][2]$%201%201e-12%202.688763906446752%2050%205%2050%0A171%20176%20192%20496%20192%200%202e-9%20300%2080%200%0Aw%20128%20272%20176%20272%200%0Aw%20496%20192%20544%20192%200%0Aw%20496%20272%20544%20272%200%0Ar%20176%20192%20128%20192%200%20300%0Ag%20544%20272%20544%20288%200%0Ag%20128%20272%20128%20288%200%0AR%20128%20192%2096%20192%204%205%20150000000%205%200%200%200.01%0Aw%20544%20192%20544%20272%200%0Ao%204%2016%200%204098%205%200.025%200%202%204%203%0A%0A%20%20[4]:%20https://www.falstad.com/circuit/circuitjs.html?cct=$%201%201e-12%202.688763906446752%2050%205%2050%0A171%20176%20192%20496%20192%200%202e-9%20300%2080%200%0Aw%20128%20272%20176%20272%200%0Aw%20496%20192%20544%20192%200%0Aw%20496%20272%20544%20272%200%0Ar%20176%20192%20128%20192%200%20300%0Ag%20544%20272%20544%20288%200%0Ag%20128%20272%20128%20288%200%0AR%20128%20192%2096%20192%204%205%20150000000%205%200%200%200.01%0Al%20544%20192%20544%20272%200%201.0000000000000001e-7%204.4651918219930954e-11%0Ao%204%2016%200%204098%205%200.025%200%202%204%203%0Ao%208%2016%200%204099%200.15625%200.000390625%201%202%208%203%0A" rel="nofollow noreferrer">short termination [inductive termination][4]$%201%201e-12%202.688763906446752%2050%205%2050%0A171%20176%20192%20496%20192%200%202e-9%20300%2080%200%0Aw%20128%20272%20176%20272%200%0Aw%20496%20192%20544%20192%200%0Aw%20496%20272%20544%20272%200%0Ar%20176%20192%20128%20192%200%20300%0Ag%20544%20272%20544%20288%200%0Ag%20128%20272%20128%20288%200%0AR%20128%20192%2096%20192%204%205%20150000000%205%200%200%200.01%0A209%20544%20192%20544%20272%200%201e-12%202.656944995198298e-7%201%0Ao%204%2016%200%204098%205%200.025%200%202%204%203%0A%0A%20%20[6]:%20https://www.falstad.com/circuit/circuitjs.html?cct=$%201%201e-12%202.688763906446752%2050%205%2050%0A171%20176%20192%20304%20192%200%202e-9%20300%2080%200%0Aw%20128%20272%20176%20272%200%0Aw%20496%20192%20544%20192%200%0Aw%20496%20272%20544%20272%200%0Ar%20176%20192%20128%20192%200%20300%0Ag%20544%20272%20544%20288%200%0Ag%20128%20272%20128%20288%200%0AR%20128%20192%2096%20192%204%205%20150000000%205%200%200%200.01%0A171%20368%20192%20496%20192%200%202e-9%20300%2080%200%0Ar%20544%20192%20544%20272%200%20300%0Ar%20336%20192%20336%20272%200%20500%0Aw%20304%20192%20336%20192%200%0Aw%20336%20192%20368%20192%200%0Aw%20368%20272%20336%20272%200%0Aw%20336%20272%20304%20272%200%0Ao%204%2016%200%204098%205%200.025%200%202%204%203%0A" rel="nofollow noreferrer">capacitive termination [conductance discontinuity][6] resistance discontinuity URLencoding the $ fixes the issue, though on a cursory search $ doesn't seem to be something that's required to be urlencoded. I did first create these links with ctrl-L and pasting the link, which did translate all the + into %20, so I guess that dialog already results in some re-encoding. An easy, if not entirely correct fix, would be to have that routine also urlencode any $.

Technical note: The mentioned workaround of replacing $ with %24 will work in most cases but should not be relied on. If you are an internet protocol enthusiast but don't want to bother looking it up yourself: The $ character is in the "sub-delims" category in RFC 3986 (whose more familiar members are the &, =, and + of query parameters), which means that web servers are allowed to interpret \$ differently than %24 if they choose to.
This is in contrast to the characters that must be treated differently when escaped, such as / and %2f (matters for relative URL resolution even if the server decides to serve /foo%2fbar with the same contents as /foo/bar), or required to treat the same (such as A and %41).