Put a .pdf file with a unicode character anywhere in the path (file name or folder name). Like ė, ų, ū and such. Try viewing it in obsidian. It is not opened. Rename it (or containing folder) to eliminate those characters, and the file is didplayed.
Funnily enought, I only started with using snap to rule out influence of non-supported installation methods for reporting another bug…
Sooooo, I should just drop the snap and use which of the installation formats and from which source? Or are there other workarounds?
I had install Obsidian with the snap tool. I tried to launch it with the following command env LC_ALL=en_US.UTF-8 obsidian, which logged:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
2025-07-22 12:08:46 Loading main app package /snap/obsidian/47/resources/obsidian.asar
2025-07-22 12:08:46 Checking for update using Github
2025-07-22 12:08:46 Success.
2025-07-22 12:08:46 Latest version is 1.8.10
2025-07-22 12:08:46 App is up to date.
Then, I uninstalled it and re-installed considering the .deb file downloaded from the Obsidian’s official downlaod website.
Also this old bug - https://forum.obsidian.md/t/some-pdfs-are-shown-as-empty-in-internal-pdf-viewer/73058 - is about the same. It’s already archived and I cannot comment on it, so I’m hoping @isomattis found that snap is the culprit.
Same issue here - with German umlauts and with all Japanese characters.
It also leads to an hard Obsidian crash on drag-and-drop of such image files into the application. But strangely only if I start with the shortcut of the application launcher.
I’m on EndeavourOS (which is Arch Linux)
The desktop is KDE Plasma.
Official Obsidian AUR image: extra/obsidian 1.12.4-1
empty test vault / no plugins
As far as I see I’m on the locale/language setting that should work: System Locale: LANG=en_US.UTF-8
How it looks … with the top chapter using an image with only latin characters. And the second chapter using several images with Japanese ones.
The fix for me is to either launch the program via terminal - just with obsidian, no env settings necessary.
Or add the env=LC_ALL=en_US.UTF-8 to the start menu/launcher shortcut.
I have no clue why that is. Just clicking on the normal shortcut that Obsidian created on install, creates the issue.
It might be something specific about my language settings - but I don’t see a Format option that Gnome users mention. KDE allowed me to have different settings for how dates, currencies and addresses are displayed - maybe it’s that. Though it would be odd.
BTW I suspect that emojis and such in file and folder also create the problem. But I didn’t try around much.
Hi everyone,
I’ve been following this thread and the upstream Electron bug for a some time. Since it bosers me and none rushing to fix it, I built a plugin that works around it: “Linux Image Rendering Fix”.
How it bypasses the bug
The plugin intercepts Markdown rendering via MarkdownPostProcessor, finds every <img> element, reads the image file directly from disk using vault.adapter.readBinary(), and replaces src with a Blob URL (blob:...). This completely bypasses the broken app:// protocol — no locale fiddling, no package switching, no renaming.
Features
Automatic — images are replaced on page open, tab switch, and file modification
Formats: PNG, JPEG, GIF, WebP, SVG, BMP, ICO
Reprocess Images command — manual refresh for the current view
Zero network requests — works only inside the vault
Zero configuration — install and forget
Coverage
I’ve tested every scenario mentioned in this thread and beyond:
Images embedded in a note — works
Hover preview (popover) — works
Viewing an image file directly — works
Images on inactive/background tabs — works (MutationObserver catches them)
There may be edge cases I haven’t found, but so far I haven’t seen a broken image the plugin didn’t catch.
Known quirks
Some scenarios have a slight delay on first load — the system needs a “warm-up” moment before the plugin kicks in.
Install
Community Plugins → Browse → search Linux Image Rendering Fix → Install → Enable
