When you attach a PDF to a note and open it in the Rich Text Editor, it only appears as a normal link.
But in the Markdown preview, the PDF is shown as an embedded viewer.
So the behavior between Markdown preview and the Rich Text Editor is inconsistent. (Issue #8277)
We can probably use this: https://www.tiny.cloud/docs/plugins/opensource/media/ along with media_url_resolver and audio_template_callback to make it display arbitrary content (approach mentioned in the issue)
I first tried implementing this approach using the media plugin with media_url_resolver, following the TinyMCE documentation.
It worked fine for things like YouTube embeds. But when I tried the same setup with PDFs that use local file:// resource paths, the iframe just showed a black screen and the PDF didnât render. I couldnât get it to display properly with that method.
While testing this, I also noticed that even if this approach worked, it would only apply when a user manually inserts a URL through the media dialog.
In practice though, most PDFs in Joplin are added using the paperclip button, which creates a file.pdf resource link in the note. These attachments already render inline in the Markdown preview, but in the Rich Text Editor they still appear as plain links.
Because of this, I ended up exploring a different approach where attached PDFs are rendered inline when the note loads in the Rich Text Editor, so the behavior matches what already happens in the Markdown preview.
Screen Recording
After trying the above approach, I tried a different way to handle this.
Instead of relying on the media dialog, I focused on the usual workflow in Joplin where PDFs are attached using the paperclip button.
In my implementation, when a note loads in the Rich Text Editor, it looks for PDF attachment links and temporarily replaces them with an inline <iframe> so the PDF preview appears directly in the editor. The original link is still kept in the DOM (hidden inside a wrapper), and when the note is saved it converts back to the original link.
This way the Markdown source is never modified, and the behavior matches what already happens in the Markdown preview where PDFs are shown inline.
I opened a PR with this implementation:
Screen Recording
It might be better if the PDF viewer is not enabled by default when a PDF link is pasted
Automatically embedding a viewer could make notes look cluttered, especially when there are multiple PDFs
Perhaps this could be controlled with a toggle in the settings (for example, a âPreview PDFâ option), or only enabled when the user explicitly chooses to preview the PDF
I agree that having a toggle makes sense, but I think it should be linked with the existing Markdown setting instead of adding a separate one for the Rich Text Editor.
There is already a setting for enabling/disabling the PDF viewer in Markdown:
If someone disables it, they probably donât want to see PDFs inline anywhere. So it might make more sense if the Rich Text Editor just follows the same setting.
Hi @Harsh16gupta,
Interesting approach. Keeping the original Markdown link unchanged and only replacing it with an <iframe> during rendering seems like a good way to avoid modifying the note content.
Linking the Rich Text Editor behavior to the existing Markdown PDF viewer setting also makes sense, since users would probably expect the same preference to apply across editors rather than having separate options.
Curious to see how this works with notes that contain multiple PDF attachments.
@Harsh16gupta One thing I was wondering about is how this might behave on mobile when a note contains multiple PDFs.
If the âEnable PDF viewerâ setting is on and every attached PDF gets rendered inline automatically, it might make long notes harder to navigate on smaller screens. For example, if a note has several PDFs, each one expanding into a full viewer could lead to a lot of scrolling and make the note feel a bit cluttered.
Maybe one option could be to show something like a small âPreview PDFâ button or placeholder, and only expand the viewer when the user taps it. That way the note stays cleaner, but the preview is still easily accessible when needed.
Another possibility could be supporting something like  for cases where users explicitly want the PDF embedded, while keeping [pdfname](file) as a normal link. That way the embedding behavior could be controlled directly from the note as well.
Just a thought from a mobile usability perspective
@varun Currently the issue is about adding it in the desktop version
While testing the raised PR I noticed another related issue in the Rich Text Editor. If a PDF is the last thing in the editor, clicking below it keeps the cursor stuck on that element instead of placing it after it.
I also noticed the same thing happens with images too, if an image is the last thing in the note, clicking below it keeps the cursor stuck on the image. Opened a separate issue for this: *#14622*
Both are coming from the same reason. In the opened PR I tried fixing it by appending a sentinel <p> after the last non-editable element but I think the fix should be more general.
How should I approach the fix.
The trailing paragraph is the standard way most editors handle this. One thing though, PDFs and images aren't non-editable because of joplin-editable. They are replaced elements (iframe, object, img) that browsers just treat as non-editable by nature.so the detection needs to check for those, not just joplin-editable blocks.
You can hook into the SetContent and NodeChange events in TinyMCE.tsx to check if the last child is one of those elements and append a <p><br></p> when needed. Just make sure the empty paragraph doesnot add extra newlines in the markdown round trip.
Try this approach and letâs discuss on another one if it fails
