PDF not rendering if under a folder with a unicode character

Steps to reproduce

Using a new vault, create a folder with a unicode character in it, in my case:

Then take a PDF and place a copy of it on the root of the vault and another inside the folder that was just created.
Using the sidebar select the PDF on the root. It will display, as expected.
Now when the PDF inside the folder is selected the PDF is not displayed.

Expected result

PDF should be rendered regardless of folder containing it.

Actual result

PDF is only rendered if folder containing it does not contain unicode characters.


  • Operating system: Linux (Ubuntu 22.04.1 LTS 64 bit)

  • Debug info:
    Obsidian version: v1.1.9
    Installer version: v1.1.9
    Operating system: #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 5.15.0-58-generic
    Login status: not logged in
    Insider build toggle: off
    Live preview: on
    Legacy editor: off
    Base theme: dark
    Community theme: none
    Snippets enabled: 0
    Restricted mode: on


Additional information

If the same vault is opened in windows, the PDF displays correctly regardless of where it is located.

Extra information:

The same behavior happens with images (tried with jpg), and can also happen if the file is in the root of the vault, if the filename itself contains any non-ascii character.

for example:

do you have this problem https://forum.obsidian.md/t/images-dont-load-if-vault-contains-non-standard-letters-such-as-e/42010/1?

Yes, it seems like it is the same issue.
At first I didn’t realize this affected images as well, so I only searched around for mentions of PDFs not loading.

I have tested it by launching Obsidian from the command line as suggested: LANG=en_US.UTF-8 obsidian

The issue is still reproducible in that case.
Only happens if there is a non-ascii character somewhere in the path of the resource to load (image or pdf).

Unlike the reported issue on the other post, I am running Ubuntu with the default Gnome shell.
I installed Obsidian using Snap, still not sure if that’s relevant here.

I see the same style of error on the developer console (ERR_FILE_NOT_FOUND, with the path where the offending character seems to be replaced by %base64).