PDF Export: Internal vs External Links and sharing

[Jopacabra]

I'm a researcher, and I've been developing a workflow recently that is coming across a problem. I keep reference papers, usually pulled from Arxiv.org, as PDF file notes in one part of my tree. Then, I'll build up a calculation or explanation that links to several of the references. After a while, I'd like to asynchronously receive some feedback from a collaborator or send an update. It's really easy to simply export the main note as a PDF, but then all of the "printed" links to references are protected links to my Trilium server. This makes sharing a note with some complicated dependencies difficult.

I could easily scrap keeping the references as files and make all references just be external hyperlinks, but then I lose out on a few things I really like. In order of priority:

1. I really like being able to have a reference show up as a node in note maps. I am super attached to this idea, even though I'm not sure it's as useful as I'm imagining. One of the really nice things is to be able to see all of the notes that reference an idea from one paper.
2. I like having access to the references offline -- although I rarely use this, it comes in handy in that one moment I need it.
3. I like being able to annotate the PDFs. I could reasonably replace the annotations with case-by-case footnotes in my notes that reference the PDFs, but then if I need to reread the reference I may have to rehash some things I don't understand.

Some things I've tried:

1. Replacing the file links with WebView notes. Here I retain feature 1, but lose 2 and 3. Not such a big deal... But, for some reason, when I print to PDF, the links still direct to my Trilium database, not to the web resource.
2. Exporting the content by copy-paste and replacing links. This is obviously really tedious.
3. Giving a second handout to whoever I send the note to directing them to the references. This is tedious, but it also sends them a bunch of links to my static server address, which I find messy and extremely distasteful.

Does anyone have any ideas on how I can either modify my workflow or convert links when I export a note? In anticipation of somehow fixing the issue, I've been keeping an attribute that links to the ArXiv page for each reference hoping there might be a scripting solution.

[dosubot[bot]]

Hi @Jopacabra! I'm Dosu and I’m helping the Trilium team.

You can use Trilium's new "share" export format to solve this. When you export using "share," Trilium rewrites internal links: if a referenced note (like your PDF reference) has a label called shareExternalLink, the exported link will point to the external URL you specify (for example, the Arxiv page), not your private Trilium server. If the label isn't present, the link points to the local copy in the export. This lets you keep all your reference notes as nodes (for note maps, backlinks, and offline/annotation benefits), but have exported links go to Arxiv or another public resource for sharing with collaborators.

To use this: add a shareExternalLink label to each reference note and set its value to the Arxiv URL. Then, export your main note (or subtree) using the "share" format from the export dialog. The resulting ZIP contains static HTML with links rewritten as described, and embedded PDFs remain viewable in the export.

PDF annotations made inside Trilium itself are not exported or visible in the shared HTML—only the PDF file is included and viewable. Note map visualizations are also not included in the export, but the note structure and links are preserved in the HTML.

This approach avoids tedious manual link replacement and keeps your workflow intact. For more details, see the implementation of the share export and link rewriting logic here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Jopacabra]

@dosu I'm struggling to use the shareExternalLink label. Here's what I tired:

I create two new text notes, A and B, at the same level in the tree. In note A, I place a link to note B. I apply the shareExternalLink label to note B (#shareExternalLink="https://arxiv.org/abs/1607.02521"). Now, I enable sharing in note A.

When viewing note A via the share link, I see something that looks like a link to note B, but it does not seem to be an actual hyperlink.

Am I doing something wrong?

[dosubot[bot]]

You're almost there—the issue is with the format of the shareExternalLink label value. It should be just the plain URL, not an XML or HTML snippet. For your example, set the label on note B like this:

#shareExternalLink="https://arxiv.org/abs/1607.02521"

Once you do this, any link to note B in a shared/exported note will become a clickable link to the ArXiv page (opening in a new tab) in the shared HTML view. No extra formatting or description is needed—just the URL as the value. This is the expected usage according to both the code and the official documentation (see docs).

Let me know if you run into any other issues!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Jopacabra]

@dosu I think that I accidentally emedded a link in my post here, but I am using the correct form of the shareExternalLink label, exactly as you describe. Do you have any troubleshooting ideas?

[dosubot[bot]]

Here’s a focused troubleshooting checklist for why shareExternalLink might not be producing a clickable external link in your shared/exported note, even when the label is set correctly:

1. The label value must be a plain URL (e.g., https://arxiv.org/abs/1607.02521), not XML, HTML, or Markdown. No quotes or markup—just the URL itself.
2. The label must be on the target note (the one being linked to), not the source note.
3. The link in your source note (A) must be a standard Trilium internal note link to the target note (B), created using the note picker or the internal link dialog. If you use a custom alias, reference-style link, or a link that doesn’t end with the note’s ID, the exporter won’t rewrite it to the external URL and it will remain a local/internal link instead.
4. Both notes must be included in the shared subtree (i.e., if you share/export note A, note B must be a child or descendant, or at least included in the export).
5. Protected notes cannot be shared, and some note types (like Web View or Note Map) are not supported in sharing.
6. If you want the note to appear as an external link in the navigation tree as well, add both #shareExternal and #shareExternalLink labels to the target note.
7. Try opening the shared/exported HTML in a different browser or incognito mode to rule out caching or extension issues.

If you follow these steps and still see a non-clickable link, try this minimal test: create two text notes, link from A to B using the note picker, add #shareExternalLink=https://arxiv.org/abs/1607.02521 to B, share/export A, and open the result in a fresh browser session. If it still fails, let me know your Trilium version, note types, and exactly how you’re creating the link.

For more details, see the official docs and the link rewriting logic in the code.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Jopacabra]

The piece I was missing was that the linked note (B) either has to be a sub-note of the note that I'm sharing (note A) or else it must be shared itself.

That's kind of sub-optimal for me, but this will work in principle. I will share my entire "References" folder full of PDFs and apply the shareExternalLink tag to each. This way, when I naturally make links back to my references, I can easily just share a link to my note.

It would be convenient if this tag (or a similar one) could be used directly in the "Export as PDF" feature, since I frequently collaborate with people in a country that categorically blocks my DNS host. For these collaborators, I can share, visit the shared note in a web browser, then print the page to PDF. Annoying, but serviceable.

AI strikes again! Thanks.