INTEGRITY Documentation

Troubleshooting

Requests without resizing enabled

Does the response have a Cf-Resized header? If not, then resizing has not been attempted. Possible causes:


Error responses from resizing

When resizing fails, the response body contains an error message explaining the reason, as well as the Cf-Resized header containing err=code:


Limits

These are the limits for images that are stored outside of Images:


Authorization and cookies are not supported

Image requests to the origin will be anonymized (no cookies, no auth, no custom headers). This is because we have to have one public cache for resized images, and it would be unsafe to share images that are personalized for individual visitors.

However, in cases where customers agree to store such images in public cache, Cloudflare supports resizing images through Workers on authenticated origins.


Caching and purging

Changes to image dimensions or other resizing options always take effect immediately — no purging necessary.

Image requests consists of two parts: running Worker code, and image processing. The Worker code is always executed and uncached. Results of image processing are cached for one hour or longer if origin server's Cache-Control header allows. Source image is cached using regular caching rules. Resizing follows redirects internally, so the redirects are cached too.

Because responses from Workers themselves are not cached at the edge, purging of Worker URLs does nothing. Resized image variants are cached together under their source’s URL. When purging, use the (full-size) source image’s URL, rather than URLs of the Worker that requested resizing.

If the origin server sends an Etag HTTP header, the resized images will have an Etag HTTP header that has a format cf-<gibberish>:<etag of the original image>. You can compare the second part with the Etag header of the source image URL to check if the resized image is up to date.