Streaming live at 10am (PST)

Responsive images not being delivered to mobile

Hey guys, there’s currently an issue on my site where Webflow is not resizing images correctly to deliver small images for mobile, see Google PageSpeed

I have used the Image is HiDPI setting on all my images, but still no resizing :frowning:

What is going on?

Here is my site Read-Only: LINK
(how to share your site Read-Only link)

Read up on how Webflow handles responsive images here ->

Hey @webdev, thanks for the response.

It seems like the article you linked is outdated — the option to enable responsive images seems to have been replaced with the image is HiDPI selector, from which Webflow does not generate photos which are appropriately resized!

Could I confirm with Webflow Support?

Edit: Looking at my source code, Webflow does indeed generate resized photos, but the resized photos are just not being delivered to the mobile site

Have you taken the time to look at the generated source code on the published site?

Yes, this is the line of code for the photo in question:

<img src="images/Mobile-Builder-Screen-2.png" loading="lazy" width="640" sizes="(max-width: 479px) 100vw, (max-width: 767px) 85vw, (max-width: 991px) 48vw, 50vw" srcset="images/Mobile-Builder-Screen-2-p-500.png 500w, images/Mobile-Builder-Screen-2-p-800.png 800w, images/Mobile-Builder-Screen-2-p-1080.png 1080w, images/Mobile-Builder-Screen-2.png 1280w" alt="">

The code says that there should be a photo that is 500px wide, but it does not seem to be loading that photo, instead loading the 1080px wide photo.

In checking the /images folder, Webflow indeed does generate to 500px wide version, it just does not load on mobile.

Edit: there are other photos which this bug affects as well, above is just 1 example

Additionally, to add — whilst this site is being self-hosted, pagespeed reports the same issue on the site as well

@cyberdave @jorn @WebDev_Brandon just confirming if this is a proper bug in Webflow

Here is a demo page with two images placed into child divs of a standard WF container. The images are identical in dimensions and almost identical in kb. I created this to simplify testing.

The second image is flagged HiDPI. You can test loading this page to see which images are loaded from the responsive sets Webflow creates for each image. My tests show the browser/device is making the determination on which asset to load. I don’t see the HiDPI as having any effect in this demo.

Image dimensions and asset information is below each image.

Demo → responsive images and HIDPI (

Alex, did you get to the bottom of this?
I just noticed if I have an image smaller than 1080 it does not even create the different sizes.
Also on Web Dev tools even though when I do have an alt image for 500px it loads the 1080px when emulating the moto G4 360px.

1 Like

Just paid for a month so I could export to verify if the responsive images were working properly and a bit disappointed to find they are not. The srcset has only two sizes, 1400 (the full size I uploaded) and 1080px, where are the sizes for mobile screens?

Anyone have any idea why this isn’t working? Thanks!


Nope no one ever helped out.

I would suspect that this has something to do with how Webflow would implements responsive images. In a lot of CDN setups, the resizing of images are done on the fly, i.e.

  1. User uploads 1 image to CDN
  2. First page view of page requests a mobile viewport image
  3. CDN generates that size image on this first request and caches it

As opposed to

  1. User uploads image to CDN
  2. CDN pre-renders image into every viewport size

On site export, this probably is a bug relating to their CDN implementation.

Hi @Alex_Pan and @Craig_Burton, thanks for your posts. the responsive image that will be used will be based on the viewport resolution of the device and the styling in the design that may constrain the image dimensions.

I can help to check each page where there is a question on the responsive images used, but I would need some additional info:

  1. What kind of device is exactly being used, make and model and operating system/OS
  2. Published page on the staging or custom domain where the responsive images are being used
  3. Screenshot of the image in question if possible.

I can help to check that source set based on the current image used.

It may also help to re-run the responsive image feature again on the project if the project is very old, see how to do that here: Responsive images in Webflow | Webflow University

Thanks in advance

Here’s a quick test project I did, images 2400 * 1600px in a flex container set to row, so at the smallest media query, they sit side by side at a viewport width of 320px, so their minimum size needed is 160px.

The smallest srcset value I get is 1080px.

This is what I get in dev tools looking at the code

these are the two images I used

derek-story-jrqeb5o7H2U-unsplash (1)

This is the published page.

I’m on windows
spec :
CPU: AMD FX™-8300 Eight-Core Processor 3.30 GHz
ram: 24gb
GPU: nvidia 1050ti


Hi @Craig_Burton,

Thanks for your response, I took a look and the original image at 2400x1600 is of type .jpeg and is already compressed quite a bit to 479kb which is a low file size for an image of that dimension.

When Webflow resizes your master image to generate the variant files, sometimes our compression can produce a variant that has a larger file size than either the filesize of the master image (if it was heavily compressed) or than a larger variant (in some cases more pixels are easier to compress than fewer pixels).

Whenever we produce a variant that has a larger filesize than the master image or a larger dimension variant we mark it as such and don’t use it on your site, since it would be more efficient to just serve the larger variant or master that has a smaller file size.

The lowest variant with file size is used which in this case at 1080px is 80kb for the responsive image, there were no lower sized variants that could be created lower than 80kb.

Do you have another example where the incorrect variant seems to be used?

1 Like

OK, I didn’t take into account that it was compressed as well. I guess when you’re used to doing it all yourself, you don’t really think of stuff like that. What would you recommend, giving best resolution available, uncompressed images and let the compression on your end take care of it?

aside: These were images from unsplash that I didn’t compress, but I took smaller resolution so they will have been on their end.

EDIT: to answer your question I don’t have a another example, I think the compression thing pretty much covers it. Makes sense.

EDIT 2 : Where are my manners? Thank you very much for the investigating and explanation. Much apreciated.

1 Like

Just tried with another test

same image, one with 50% contrast (use contrast filter to restore, saves kb)

at the smallest size I downloaded the images from published site and got
these back, they are 40kb and 67kb respectively. It seems the compression can go under 80kb (that’s good for tiny pics, thumbnails etc, I’m happy) it just seems to not want to go under 1080px for the size, which is ok for small stuff, but makes me wonder if it shouldn’t be using a bigger size file for images that actually need to be 1080.

EDIT: just set viewport to 1079, so should still get 1080 image, but downloaded it and got the 1600 size, which given the size of the image files is probably a good thing.

Conclusion: the feedback webflow is giving back about sizes doesn’t appear to match what is happening (unless I’m missing something) HOWEVER, it does seem to serve appropriate sizes that look ok and are compressed decently. Seems like, although I may not know what’s happening from the code, the end results appear to be working fine. So I will trust WF to get this right until I have a reason not to.

Sorry I got so nerdy testing this, but it is good to know things are working as intended

1 Like

Hi @Craig_Burton, thanks for your reply, the native resolution of the device and monitor used also make a difference on which variants are loaded.

From my initial look, the first image is having an initial upload size of 2.8mb, with a dimension of 3600x2400, so the image at time of upload has already been compressed it looks like, but how much I am unsure exactly. The file size is about 75% of the max image weight in Weblflow (4mb).

On any device or monitor that has a native resolution of 1080px or higher, the 1080px image will show unless the native resolution of the device is lower than 800px AND where an 800px or lower variant exists.

For example, if you had an image that was 300px and the max resolution of the device you are viewing the image on has a higher resolution, then that higher resolution will be used for the css media query and the first variant that is higher than the resolution width in the css media query will be used.

Consider the following real world examples:

Viewport size for Moto G4 - 1080px

Since the native resolution for the Moto G4 is 1080px the 1080px image is used

Viewport size for older Apple IPad - 1024px

For the old iPads, which are 1024px wide, the 1080px image is used as that is the next widest image variant that is wider than the viewport.

Viewport size for Apple IPhone 6 - 750px

The Viewport size for Apple iPhone 6 is 750px. In this case the 800px wide variant would be used, however if the lowest sized variant that could be created in terms of file size was 1080px, then the 1080px variant size would be used.

If there was a 300px wide image in the layout and a 500px variant exists, then the 500px variant would be used.

It is good to keep in mind, you can also pre-create your images with relative dimensions according to the planned layout, if the image dimension/file size cannot be improved upon through the responsive image feature, then the original image that is uploaded will be used.

The compression is not perfect, sometimes you will get some unexpected resizing result.

In those cases where absolute lowest image weight is needed, I like to pre-compress the images and resize the image to 500px or lower and max compression prior to upload to Webflow if you want to get the absolute lowest possible image dimension and file size.

If you upload larger images and pre-compress them, then your results as to how many variants are created will vary.

Usually if you upload totally uncompressed images, you will end up with all variants (or more variants).

I hope this helps, let me know in case of any questions.

1 Like

Brilliant info, thanks a lot Dave. There’s a lot for me to chew on there. I was already pretty content that WF was doing a decent job resizing images after extensive poking around. But I will take your advice about super small sizes.

Thx again

1 Like