Inline pdf previews

I really don’t know so this is just waste of bandwidth but Safari has been problematic before because of its quite hard CSP rules and other security matters. But it should then break all Safari versions, not only Mac’s,I reckon.


It works for me in Mac Safari. The only place where it does not work for me is on an iPhone (Safari, FF, and Chrome). I haven’t tested on iPad recently.


All web browsers on iOS/iPadOS use the exact same rendering engine (WebKit) due to Apple’s restrictions, so that wouldn’t really matter anyway.


Here is what I see on my new MacBook Air, Safari v. 14.1.1

I must have a wrong setting somewhere…


Try updating Safari to the latest version.


I just pushed a new update.

You can now disable the preview for specific PDF files. It doesn’t work exactly like oneboxes because that would be a bit complicated to implement in a theme component, but it’s very similar.

When you upload a PDF, you’ll see this in the composer by default.

[file.pdf|attachment](upload://2cLML0SIwebGHDjlKRVzZ3VRv0f.pdf) (524.1 KB)

All you need to do is add a space before the file name like so

[ file.pdf|attachment](upload://2cLML0SIwebGHDjlKRVzZ3VRv0f.pdf) (524.1 KB)

Note that the space needs to be inside the brackets. It won’t have any impact on the file name when you download it, and it will also not have any impact on the file description rendered in the post.

Once you do that, the PDF will not have a preview attached to it in the cooked post.

The update adds a new setting.

It has two options.

Inline and New Tab

If you select Inline PDF previews will be rendered in the post like before.

If you select New Tab the component won’t create an inline preview. However, the link for the attachment will open a new tab. The new tab will display the PDF file in the native browser reader.

and the icon next to the attachment link will change to external-link instead of download

The default for the setting is Inline So… it won’t affect sites that had this component installed before the update. It only adds a new option that you need to toggle.

There have been some reports about this not working on Safari and some iOS devices - which I haven’t been able to reproduce. The update tries to address that by loading the PDF as a base64 URL instead of a blob - which I read is very finicky on Apple devices.

Please update the component - and make sure your browser is updated as well. If, for some reason, it doesn’t work for you on an Apple device, please check the browser console - if possible - and let me know what you see.


Since updating to latest, 2.8.0.beta6 (a1daf9fe53), PDF previews seem like they are loading slightly slower, and in at least one case, one PDF out of three in the post doesn’t show up in Chrome:

It’s not a caching issue - even after clearing Chrome’s cache, saving the PDF with a slight change and re-uploading, the preview still won’t show up. There are no entries in the error log. Chrome is updated to latest.



I’m on 2.8.0.beta6. PC - Windows 10. Similar observation. Firefox is a bit slow, but the preview eventually loads. Chrome won’t show it, it seems to freeze on this gray placeholder.


Thanks for the details. Since two of those loaded fine, I figured that it probably has something to do with the file size… and it turns out that is indeed the case.

If I upload a large PDF, it works fine in Firefox but chokes on Chrome. I read a little bit about this, and it seems like the length limit that a base64 URL is largely decided by the vendor. Firefox has no limits. Chrome caps them at 2mb.

So, this means that a base64 URL is not a viable option, and we’d have to go back to blob URLs. It seems safari has better support if the preview element is an <object> tag instead of an iFrame.

So, this PR changes everything back to a blob URL and changes the tag to <object> This will definitely resolve the issue for large files on Chrome and hopefully :crossed_fingers: fix the issues on Apple devices.

Please update the component again and let me know if you still have any issues.


The file sizes in the post with 3 PDFs are 548.3 KB, 1.1 MB, and 1.6 MB, in that order from the top. After updating the component alone, the previews do show up, but no longer at full width in Chrome:

EDIT: FF looks the same as Chrome above and Safari is not showing previews, but gray boxes:


Thanks, I pushed a small fix for the size issue.

UX: adds missing iFrame attributes by hnb-ku · Pull Request #4 · discourse/discourse-pdf-previews · GitHub

It probably won’t fix the issue on Safari, but please try and let me know.


Yes - Chrome and FF are fixed, Safari remains the same with just the gray boxes.


Just to confirm, Safari used to work for you before, right?


Yes, up until the recent update all desktop browsers were working fine. I can’t say how far back Safari was OK because it’s not my daily browser, but I can say that it has worked sometime in the past.


This commit should fix Safari.

FIX: previews are still broken on MacOS safari by hnb-ku · Pull Request #5 · discourse/discourse-pdf-previews · GitHub

I just tested it on a MacBook, and it works fine for me in Safari, Chrome, and Firefox.

If anyone sees this issue

It’s an issue in your setup, not in the component.

How to unblock a blocked plug-in to displ… - Apple Community

Also, please note that this component never supported PDF previews on mobile phones - as defined by Discourse, whether it be iOS or Android. So, that’s the expected behavior.


Excellent! Thanks @Johani. I can confirm it works in all 3 browsers now.


Fantastic - these are solid improvements and clearly a lot of work to achieve. Thanks for listening to us slightly annoying co-conspirators in the self-hosted world!

Does the Component now work with S3 uploads?


I haven’t tried it, but It should work if your bucket is configured correctly. This component makes a request to load the PDF

discourse-pdf-previews/initialize-for-pdf-preview.js at main · discourse/discourse-pdf-previews · GitHub

These types of requests made in JavaScript are blocked if the origin is not allowed access to the file. You then end up with a CORS error. If you check the console, you’ll probably see something along the lines of this.


There’s not much the component can do about this. It all has to be handled in your S3 configuration. The origin - your Discourse domain - must be allowed to make such requests to avoid CORS issues.


Thanks! I’ll bravely take the plunge back to S3 shortly.

Another suggestion: tab when space before filename

What I want is for the pdf to be inline by default, and to open in a new tab if the space is put in the filename. This gives authors the choice per pdf of inline vs tab rather than per component.

Perhaps the component setting should instead be “What default behaviour do you want?” and if a space is put in you get the other.

Or alternatively you could ask what the space should do (inline / tab / download).


Aargh! Chrome is again showing only gray boxes. FF and Safari are OK.