Hey, I am hosting a pdf on sanity and put it in a link on a webpage, recently I discovered that in safari it shows `Blocked plug-in` when clicking the link. This behavior...

6 replies
Last updated: Sep 28, 2020
Hey, I am hosting a pdf on sanity and put it in a link on a webpage, recently I discovered that in safari it shows
Blocked plug-in
when clicking the link. This behavior is new to me and I do not have it with other pdf links. Does anyone have an idea why this is and what how to solve it? It is not just on my safari browser but as well on the one of my aunt (she’s the owner of the webpage I build and it already runs for almost 2 years now)
here is the part of my code:


{/*This was a test link where which works fine for me*/}
<a href="<https://blog.bernina.com/de/wp-content/uploads/sites/2/2016/07/Schnittmuster-A-kleid.pdf>" target="_blank" rel="noopener">Schnittmuster A-Kleid</a>
{/*This gives me the blocked plugin problem: */}
<a href="<https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf>" target="_blank" rel="noopener">Aktuelle Verhaltensregeln / Hygienemaßnahmen.</a>
AI Update

I understand this is frustrating, especially since it's worked fine for 2 years and suddenly started causing issues in Safari. Based on your code example, this appears to be a Safari-specific behavior rather than a Sanity CDN issue.

The Sanity Asset CDN serves PDFs and other files reliably across browsers - it's built on Google's global CDN infrastructure and handles caching for files up to 5 TB. The fact that your PDF works in other browsers and that your comparison link (the bernina.com PDF) works fine in Safari suggests this is about how Safari is interpreting or handling the specific way the file is being served.

What's likely happening:

Safari's "Blocked Plug-in" message typically appears when Safari's security policies prevent certain types of embedded content from loading. This can be triggered by:

  1. Content Security Policy (CSP) headers on your website that restrict where plugins/objects can load from
  2. Safari's evolving security policies that have become stricter over time (which would explain why this is new behavior)
  3. How the browser interprets the link when opening in a new tab with target="_blank"

Practical troubleshooting steps:

1. Check your website's Content Security Policy

If your website has CSP headers configured, Safari might be blocking the PDF because cdn.sanity.io isn't explicitly allowed. Check your server's response headers or meta tags for CSP directives. If you find them, you may need to add:

Content-Security-Policy: object-src 'self' https://cdn.sanity.io;

Or if you're using frame-src or default-src, ensure cdn.sanity.io is included there as well.

2. Test without target="_blank"

Try temporarily removing target="_blank" to see if opening in the same tab avoids Safari's blocking:

<a 
  href="https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf" 
  rel="noopener"
>
  Aktuelle Verhaltensregeln / Hygienemaßnahmen.
</a>

3. Check Safari's settings

Have both you and your aunt check Safari's settings:

  • Go to Safari → Settings → Websites → Plug-ins
  • Look for any blocked items related to PDFs or the specific domain
  • Also check Settings → Websites → Pop-up Windows to ensure nothing is being blocked there

4. Consider a download attribute (with limitations)

You can try adding a download attribute to force a download instead of inline viewing:

<a 
  href="https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf" 
  download="verhaltensregeln.pdf"
  target="_blank" 
  rel="noopener"
>
  Aktuelle Verhaltensregeln / Hygienemaßnahmen.
</a>

Note that the download attribute may not work for cross-origin resources unless the server sends appropriate CORS headers, but it's worth testing.

Why this might be Safari-specific:

Safari has historically been more restrictive than Chrome or Firefox when handling cross-origin resources and embedded content. The Sanity CDN is working correctly - it's Safari's interpretation of how to handle that content that's causing the issue. The timing (new behavior after 2 years) aligns with Safari's regular security updates.

Next steps:

Start by checking for CSP headers on your site (option 1), as this is the most common cause of "Blocked Plug-in" errors. If you don't have access to server headers or that doesn't resolve it, testing without target="_blank" (option 2) will help narrow down whether it's specifically about new tab behavior. The Safari settings check (option 3) is worth doing to rule out user-level blocking.

If none of these resolve it, you might consider using a JavaScript PDF viewer library like PDF.js for a more controlled rendering experience that doesn't rely on Safari's native PDF handling.

Hi Sari, thanks for reporting this. It seems to be an issue with the Adobe plug-in and how plug-ins work in Safari in general, i.e. it’s not specific to your implementation, although that still doesn’t explain why it works with the other PDF in your code. Both links open the PDFs inside the browser, correct? And you’re not opening one of them in a separate tab but clicking both from within their own tab?

The latest versions of Safari use a new plug-in manager for enabling and disabling plug-ins on a global or per site basis. The Acrobat and Reader PDF viewer plug-ins are not trusted by default until you actively trust the plug-in globally, or for each website.
It seems be a common issue with some reports of it being resolved when people update Safari or Adobe Acrobat Reader, but other reports that it simply keeps showing the blocked plug-in warning.
I do see this in the console, which I’ll forward to the team just in case:

Refused to load <https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf> because it appears in neither the object-src directive nor the default-src directive of the Content Security Policy.
Shift-clicking the link to the PDF to open in new tab, or simply CMD+S to save it, should still work. It’s the preview that’s the issue in this case.
Also, you could try adding
?dl
at the end of the URL to force a download instead of an in-line preview if that’s a workaround? 🙂
Actually, there was a recent change in our content security policy that might have been a little too strict here. This was fixed just now, but just to make sure the CDN is not serving the old CSP headers, one of our devs recommends adding
?cache=break
temporarily:
<https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf?cache=break>
[Edited post above for extra context]

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?