Workers Sites, Missing Images

Using Wrangler to deploy a static site, certain images that are present and displaying fine when I display the site locally do not seem to make it onto the Cloudflare version.

I am deploying the entire site using

wrangler publish --env prod

In one test site, the main logo does not appear. When I attempt to open the image in its own tab I get this error:

could not find img/logo.png in your content namespace

The image in question is 27 KB, and I removed all files above the Workers Sites limit of 2 MB before my first attempt to deploy.

Should I be deploying individual folders to make sure that everything gets uploaded?

I would appreciate any advice. I am excited by the potential of Workers Sites but am painfully aware that, at present, there appears to be no easy way to view what has actually been successfully uploaded.

Ah, the problem appears to be that Workers Sites is far more fussy about the use of capitals than Netlify, where I previously had this site.

Again, it would be a lot easier to troubleshoot this stuff if there was some sort of file list to see what Cloudflare has.

Interesting – can you give an example @imappoet?

Hi @signalnerve

Okay, so, as I mentioned, I came across this behavior because I am moving static sites from Netlify to Workers Sites. Some images were not appearing.

My understanding is that Web servers ignore capitalization in URLs and file names. So, for example, if a URL requested the file coffee.jpg but only a filed named Coffee.jpg was in that folder, that file would still be served.

Likewise, sandwich.jpg would be considered the same as Sandwich.jpg

Here, using a site hosted on Workers Sites, we can see how URLs containing the variations described above do and do not work:

… so, as you can see, Cloudflare strictly enforces the difference between capitalized and uncapitalized letters.

Here is the same page and image files hosted on Netlify:

Users transferring sites to Cloudflare from Netlify (or other hosts following the same conventions) are likely to run into problems, which will be an ongoing support issue for Cloudflare. Worse, some sites will have a less obvious problem, such as just a few non-displaying images that the site owner won’t notice, but visitors to that site will not have the intended experience.

Unless there is some other reason to be so strict, it might be a good idea to start being more flexible about capitalization.

Windows = Case insensitive. Linux = Case sensitive.

I guess since Cloudflare Workers run on Linux, they opted for the default.

Many are confused though, because SEO-friendly URIs on Apache and Nginx servers are case insensitive by default.


This is likely because of how Workers Sites work.

Behind the scenes, it’s just a KV store:

And KV itself is case sensitive since a key-value store that’s case insensitive is not necessarily something developers want.

So the only way you could get what you’re looking for is if Wrangler/Workers normalized the path both during upload and during pull, something not currently offered out-of-the-box.


something not currently offered out-of-the-box

Probably a good idea to add this as a Wrangler option!

1 Like

We do have the KV browser, which can show you this. After logging in, go to the workers dashboard on the bottom right:

click kv


This will show your namespaces. the ones for Workers Sites have this name. Your ID should be different, of course, this is mine:

If you click view:

There’s the hash included, but you can at least see what’s in there.


One option to fix this is to modify the mapRequestToAsset property passed into the getAssetFromKV function in your workers-site/index.js file

For example, assuming you have all lower case files, make all requests look for the lowercase key in the KV store:

    return await getAssetFromKV(event, {
      mapRequestToAsset: request => {
        // compute the default (e.g. / -> index.html)
        let defaultAssetKey = mapRequestToAsset(request)
        let url = new URL(defaultAssetKey.url)

        // make all requests Lower case
        url.pathname = url.pathname.toLowerCase()

        // inherit all other props from the default request
        return new Request(url.toString(), defaultAssetKey)

Oh, that’s terrifically useful, I’m surprised I didn’t find that when I was poking around, thanks Steve.


Thank you to everyone who responded.

I now think the best way for me to catch this is to create a check in the WordPress plugin I’m using to generate static sites, WP2Static.

Then I will find some way to automate checking the deployed sites for any non-displaying images or other requests that result in errors.

Hey @imappoet, glad the team was able to help!

Out of curiosity, I’d love to hear about how migrating sites from Wordpress to WP2Static is working for you. I’ve been exploring the topic and would love to chat about it :slight_smile: Want to shoot me an email? kristian AT cloudflare.