catbox.moe invalid uploader (HTTP 412) and the free image host that worked

The symptom

I needed public URLs for a batch of images, specifically to fill the Media URL column of a Pinterest bulk CSV, and I was working from a corporate-proxied Windows machine. Every obvious path either failed outright or produced URLs that did not serve the image.

What was happening

Each of the usual suspects died in its own way. A hand-rolled Cloudflare Pages direct-upload script created a deployment successfully, so it looked like it worked, but it never stored the asset blobs and the resulting URLs returned HTTP 500 (wrangler itself was a non-starter, because the proxy blocks it). catbox.moe returned HTTP 412 “invalid uploader”. 0x0.st returned HTTP 503 with uploads disabled.

So I had a deployment with no bytes behind it and two throwaway hosts that were down or blocked. Anything needing an unproxied client connection or a flaky free endpoint was not going to be reliable from this machine.

The fix

GitHub plus jsDelivr. Push the images to a public GitHub repo, then serve them straight off jsDelivr’s CDN. The gh CLI was already authenticated, so this went through the proxy fine:

# images already in ./images on a public repo
gh repo create my-user/pin-images --public --source=. --push

The public URL for any file then follows a fixed pattern:

https://cdn.jsdelivr.net/gh/<user>/<repo>@main/<path>
# e.g.
https://cdn.jsdelivr.net/gh/my-user/pin-images@main/images/img01.png

Verified with a HEAD request: HTTP 200 and content-type: image/png. It is permanent, CDN-backed, and free. For the Pinterest case it does not even matter long-term, because Pinterest re-hosts the image on its own servers when the pin is created; jsDelivr only has to serve it once during creation.

The lesson

When wrangler or a direct-upload script is blocked, GitHub plus jsDelivr is a dependable free host for public static files and images. A public repo and the @main jsDelivr path give you a stable CDN URL without touching any blocked tooling.