Problem description:
Replit’s markdown preview doesn’t properly resolve links that contains spaces in filepaths if those files are local to the workspace.
Expected behavior:
Spaces in filepaths should not affect link behavior in MD preview.
Actual behavior:
Links to URLs that contain spaces do not work. In particular, I just want to be able to reference another file in the workspace.
I have tried using <> notation (which CommonMark indicates should be supported for any minimum MD implementation). File can’t be found.
I have tried using %20 - file can’t be found.
I have tried using just spaces (Markdown just converts all spaces to %20 anyway. I suspect this may be part of the problem, see the attached image for the error message.)
Create a file with any space in the full filepath (can be in the filename or a parent directory).
Attempt to link to that location in a Markdown file.
I’ve tested this with images, videos, Excalidraw files and other Markdown files. It appears that all paths are being formatted as URLs even if the referenced location isn’t remote to the workspace.
I appreciate the link, but this is not the problem. These don’t work in Replit’s Markdown preview when the target is a local file. That’s the bug.
More explicitly - the bug is that the markdown preview treats all links as URL encoded. That’s fine - if matching against local files compares against the local filepaths also being URL encoded.
I understand. I did more research and tinkering and found the cause of the issue and a workaround. This issue should be fixed.
Problem:
When you link in a repl markdown such as [my link](my_file.py), the link becomes something like https://replit.com/@username/my-project#my_file.py. In addition, special characters in the my_file.py name (there are none here) are URL encoded because it needs to create the link to the replit file (it’s really just a shortcut to creating the repl file link).
Unfortunately, spaces will make a repl MD link invalid, it will not be formatted (because URLs don’t contain spaces). So file names like my file.txt cannot easily be linked to. If you try [link](my%20file.txt), then it encodes the encoding, becoming the link https://...#my%2520file.txt.
The workaround:
Consider the MD link [my link](<my file.txt>). This allows space to be used, but unfortunately it gets double encoded, the space becoming %2520. Weird.
Now, I was out of options but I tried [my link](<#my file.txt>) and this somehow works.
TLDR:
I reproduced the problem, the common fixes don’t work, this needs to be fixed.
A workaround is: [my link](<#my file.txt>)
@NuclearPasta0 - Thanks for poking around at this some more.
It does look like that works for links at least. Unfortunately, it doesn’t seem to work properly for embedded images, videos and drawings, which is primarily what I want to use this for. The reference works, but the embeds don’t function properly.
For example, this does not work:
The video player shows up in the doc, but isn’t functional.
And for drawings: 
That is unfortunate.
The workaround can give a link to a file but the link does not point to an image or video, just to the editor. It is not an “image address”, it does not host images.
A very old thread encountered a similar problem (replit supports it now though). https://replit.com/talk/ask/broken-link-when-imbedding-image/117737
Though replit MD now supports local images, it probably uses some extra behavior behind the scenes so, no workaround for special file names.
The thread suggested using paste.pics website, then using the absolute url to that, which is of course a way but not very convenient.
This does seem like a more uncommon issue, for most cases one can replace all of the spaces with something a bit more friendly like underscores.
Depends on who you want to be friendly for, I guess. We have some ways to work around this, sure, but I’d really prefer that the behavior is just consistent with what I would expect from other MD renderers.
I was able to reproduce as well and we’ll bring it up with our internal teams for discussion on how to improve this behavior going forward. Thanks again and have a good rest of your day.
@SuzyAtReplit - I invited you to a repl that demonstrates the exact issue that I’m seeing. Small example with just a couple of embedded excalidraw files. The same behavior exists with images, videos, etc. Of course, feel free to disregard if that’s not helpful.
