# Default support for wiki-link to PDFs
**URL:** https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958
**Category:** Ideas
**Created:** [March 10, 2026, 1:10pm UTC](https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958 "2026-03-10T13:10:41Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Al3cLee](https://community.silverbullet.md/u/Al3cLee)
#### Post date: [March 10, 2026, 1:10pm UTC](https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958/1 "2026-03-10T13:10:41Z")
Use case: directly link to PDFs in the space via wikilink syntax, without the help of any plugin. This would not be so hard, since if a link ends with `.pdf` it will be automatically picked up by the PDF viewer of the browser. We just have to tell the wikilink parser: insert `.fs/` before any PDF link.
Currently I do something like
```space-lua
function noteLink(noteName)
local base = js.window.location.origin -- get the basename of url
local notePath = base.."/.fs/typeset-notes/"..noteName.."/"..noteName..".pdf"
-- manually insert the /.fs/ part
return "["..noteName..".pdf]("..notePath..")"
end
function refLink(refName)
local base = js.window.location.origin
local refPath = base.."/.fs/Refs/"..refName..".pdf"
return "["..refName..".pdf]("..refPath..")"
end
```
so that I can both access PDFs from my server and enjoy quick loading of PDFs when running in `localhost`.
I'm aware of the wonderful Silverbullet-PDF viewer, but in my honest opinion supporting PDF links (we already have custom wikilink support for images anyway) could make the onboarding experience feel nicer.
---
### Author:  [@Al3cLee](https://community.silverbullet.md/u/Al3cLee)
#### Post date: [March 10, 2026, 1:20pm UTC](https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958/2 "2026-03-10T13:20:40Z")
This could be as easy as
```space-lua
function pdfLink(path) -- Use this with the full path, including file extension
local base = js.window.location.origin
local url = base.."/.fs/"..path
local name = path:match("([^/]+)$")
return "["..name.."]("..url..")"
end
```
---
### Author:  [@MrMugame](https://community.silverbullet.md/u/MrMugame)
#### Post date: [March 10, 2026, 3:28pm UTC](https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958/3 "2026-03-10T15:28:37Z")
Does this not work out of the box? If no document editor is installed SB should fall back to opening that document in a new tab through the fs link.
---
### Author:  [@Al3cLee](https://community.silverbullet.md/u/Al3cLee)
#### Post date: [March 10, 2026, 3:43pm UTC](https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958/4 "2026-03-10T15:43:34Z")
Yes it does get forwarded, but it seems to trigger a popup which might get blocked (Safari on mobile seems to block all popups by default...). In the cases where the popup is allowed, an error "fail to navigate" is thrown, which could be misleading.
Also there is some speed difference between wikilink-fslink and direct fslink, I am not sure why or whether reproducible.
---
### Author:  [@MrMugame](https://community.silverbullet.md/u/MrMugame)
#### Post date: [March 10, 2026, 5:14pm UTC](https://community.silverbullet.md/t/default-support-for-wiki-link-to-pdfs/3958/5 "2026-03-10T17:14:54Z")
Yes the failed to navigate error is a bit misleading, it stems from an implementation detail and isn't completely wrong "Couldn't find document editor", I couldn't think of a no hack solution to this when I implemented it.
Yes, it does open it in a new tab, but this is the case for any link leading to a third party, they all open in a new tab, this is also true for your solution. It uses the exact same navigation logic as the default fallback behavior.
The speed difference probably stems from the fact that it tries to find if there is a document editor for that file. It should really not be that big of an issue, navigation should still be plenty fast