How to resolve the blob: (blocked:csp) Error?

This article discusses the details behind resolving the blob: (blocked:csp) error and discusses the details behind the Content-Security-Policy implemented within the browsers to provide additional security.

What is this article about?

These days it is typical for web pages to add “Content Security Policy” (CSP) meta tags to their website to further prevent malicious vulnerabilities. But at the same time, your website may leverage scripts from Open Source frameworks delivered via a Content Delivery Network (CDN) as part of your application or web page.

This example walks you through a typical example where your Content Security Policy does not allow additional call backs that maybe essential for supporting a blob callbacks.


When you see a “blob: (blocked:csp)” Error, you can fix it by modifying and adding an allowance for a blob URL callback.

Your solution will look like this:

  content="script-src 'self' 'unsafe-inline' blob:;"/>

Notice the “blob:” in the Content-Security-Policy directive under ‘script-src". You can read that directive (loosly) as this:

Allow the code delivered from the CDN ‘’ to make calls for JavaScript and WebAssembly resources (script-src) including ‘blob:’.

Now here is a typical (more realistic example) of other allowances that are thrown into the mix:

    default-src 'self' ; 
    style-src 'self' 'unsafe-inline'; 
    font-src 'self' data:; 
    script-src 'self' 'unsafe-inline' blob:; 
    connect-src 'self' ws://localhost:*; 
    img-src 'self' data:*;

If you are interested in the details, stick around and read onwards…

Detailed Analysis

What is a Content Security Policy?

Content Security Policy (CSP) is a whitelisting mechanism that allows you to declare what behavior is allowed on a given page. This includes where assets are loaded from, where forms can send data, and most importantly, what JavaScript is allowed to execute on a page. CSP is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

You can learn more about CSP at these resources:

Recreating this error

I was trying to integrate the Crayon by “Fresh Works” into my application development I was working with. Crayon is a Web Component framework with a good, clean implementation with a good variety of UI components (all developed using Web Components as the basis).

Here is an excert from their own words from the Crayon website:

Freshworks Crayons is a library of UI components that are the building blocks to help create an intuitive and uniform user interface for all your apps. Crayons helps developers build apps that adhere to the UX standards set by the Freshworks Design System.

What is a “Design System”?

A design system addresses how all of the properties around your apps and websites look, feel, sound, and act. Implementing them involves developing a centralized library of UI Web Components that can be shared across teams and projects to simplify design and development and avoid duplication of effort, while ensuring consistent brand experiences, performance, and accessibility, all at scale.

What is the business value in developing a “Design System”?

When done right, implementing a design system means that developers no longer need to spend time thinking about how to build components or how to tackle repeat problems that are common to every app, such as application search, calendar widgets, or data table grids. Instead, a rich library of custom UI components shared across all projects allows developers to focus on what matters most: solving customer problems and delivering value.

At this point, we are diverging from our intent of this article so let’s come back to the main thread…

There are several ways to integrate their Crayon web components into your website or application. One of the popular (easy to use) method involves pointing to their content delivery network URL where the pre-built distributions are available.

Why bring them all in (as project sources), when your application does not plan to levarage any front-end application-tier such as Angular, React or something along those lines. In my case, I’m pairing up with HTMX + Alpine.js + Bootstrap + Crayon (front-end), Golang + Fiber (middle-tier), PostgreSQL (back-end) for this application I have in mind as a pet project. In this example, there is no need for a JavaScript/TypeScript “package.json” or any need for Parcel, Rollup or Webpack JavaScript minifier or package bundler. So in this example, it makes sense to simply bring it in from the CDN source directly. If this becomes an issue, then you can download the distribution files and serve it as part of the /static/** resources.

When you integrate your web application to pull the Web Components from a CDN like you will see this issue.

[Credit where credit is due… Thank you “JSDelivr” for providing this excellent service to the development community 🫶🏻]

The crayons.esm.js file makes a “blob:” call to redirect and pull down the JavaScript generated binary-content. And that is where you see this “blob: (blocked:csp) error”.

Your case may be similar in nature. If so the solution discussed up above in the TDLR (a varient of such a exception rule) should help solve this issue.

This brings us to the last question in this inquiry…

What is a “blob:” call (or “blob” URL)?

A Blob, a concise term for Binary Large Object, is a datatype adapted to housing binary data. A Blob URL, in turn, is a unique identifier assigned to a Blob object, serving as a powerful reference for developers to manipulate binary data flexibly and efficiently. It is utilized frequently in JavaScript to facilitate a combination of the three operations:

  1. Optimized Data Transfer
  2. Client-Side File Handling
  3. Dynamic Data Storage

^ except from blog by Alisha Bhale on Hashnode

Some Resources on Blob and Blob URL:


Hopefully you got a good understanding of the following topics:

  1. What is the nature of this “blob: (blocked:csp)” error, how and why it is thrown by the Browser?
  2. Typical use cases where this error us thrown (when you bring in source code from a CDN that needs to generate a blob)…
  3. What is a blob or a blob URL? How is it used in JavaScript?
  4. What “Content-Security-Policy”?
  5. How to add or extend your CSP META tag to allow/whitelist those exceptions and continue to leverage Web Components delivered from CDNs?
  6. How to address this particular issue when is used for content delivery with follow-up JavaScript calls made to a “blob:” URL?
  7. How to avoid this issue when you you decide to use Freshworks Crayons into your web application via the JSDelivr CDN?

That was a good solid weekend of debugging and discovery shared here in a nutshell with some useful resources as follow up items to enhance your understanding.

I hope this helps you in your quest.


If you would like to show your support then consider subscribing below and/or buy me a cup of joe (I live on coffee and coffee makes me a better scribe):

Buy Me A Coffee

Today’s Quote

Kural 515:
அறிந்தாற்றிச் செய்கிற்பாற்கு அல்லால் வினைதான் சிறந்தானென்று ஏவற்பாற் றன்று.
Don’t engage in an activity on the assumption that someone else is better than someone who has the ability to study and complete it.
- Thiru Valluvar ( His Work )