Jump to content

Prevent Image Compression 7.1

Recommended Posts

  • 2 weeks later...

I have talked with live chat about this issue. Basically they will say its your fault without saying it directly. All my images are perfectly sized, color space etc... but still they compress the images. Sorry not much help, they deny that they compress images on 7.1. 

Looking at your site the quality looks pretty good. I wouldn't stress about it.


Link to comment
  • 1 year later...


I'd be surprised if there was a way to turn off SS's compression of images. There is no SS interface option for this in a site that I've seen. There might be some image formats that are less prone to bad compression.

Could you post an example of one of your images here that looks good. For all we know the forum software may also compress images. So check it out after you upload and let us know if it still looks good.

I'd like to see what SS is doing to the image and try a few different formats.

@derricksrandomviews might have some thoughts on this issue. I believe he may have uploaded a fair number of images to SS.


Find my contributions useful? Please like, upvote, mark my answer as best , and see my profile. Thanks for your support!

Link to comment

One thing that I have noticed is that squarespace definitely does store multiple versions of a picture on its content delivery network. this makes sense, there's no way you want a 20MB picture downloading and then fit it into 300px wide, page load times would be insane. So what happens is it uploads the original, but it then resizes a number of versions, which it then accesses by applying a query string to the picture request. something like this:


the ?format=1500w returns an image 1500 pixels wide, but it doesn't [seem to] do this dynamically (if you put in format=1423w you'll still get a 1500w image.

In the support files they tell you the 7 image sizes they store: Formatting your images for display on the web – Squarespace Help and the largest is 2500 pixels wide.

the image element in the source is actually switched by javascript

     style="width: 100%; height: 100%; object-position: 67.2862% 10.4886%; object-fit: cover;"

note that the data-src has the path to the original upload, but the actual src (which is the one HTML renders has the ?format=2500w on it. make your browser a bit thinner or do it on mobile and refresh the page and you'll probably get the 1500w or the 1000w instead.

I'm pretty new to commenting on these forums, so maybe you guys know all this and this isn't what you're talking about, but storing these multiple versions will obviously compress at some point. My guess is make sure that you upload at exactly 2500 pixels wide and do that initial resize yourself in photoshop or similar and play with the settings there to get the best image you can.

As for turning it off, you can't, but there's an interesting note in the file that says


Note: Images uploaded via Site Styles, such as background images, always display at their original image width. We recommend loading these images with a maximum of 2500 pixels along their longest edge. For more tips, see Image best practices below.

so I read that as, if you want to load up a file unadulterated then upload it as a custom file in your custom css bit and then reference the file by that URL.

maybe that will help someone

Dave Hart. Software/Technology Consultant living in London

Link to comment

I'm also going to add here a more simplistic thought:

when 7.1 adds a picture as a section background there's a 10% opacity overlay applied, which maybe people haven't noticed. that will darken/desaturate slightly, so make sure that's dragged back to 0%  to see the original section background colours!


Dave Hart. Software/Technology Consultant living in London

Link to comment

@iamdavehart It's a nice summary of how image handling works in SS.

To all others. Another facet of this image upload/compression scenario is that the very nature of compression is loss of information. Some images will just look bad. Although this is not specific to this situation. A client was uploading videos to YouTube. YouTube also does compression. Although the vids looked great on their recording device they looked terrible on YT. The issue seemed to be that the subject of the videos, inanimate sparkly rotating objects, just didn't take to YT's compression.

The take away is that there are some edge cases where "the system" doesn't work as well a desired. I don't know if that is the case here as we've not got an image to play with to see if we can get a better result.

Find my contributions useful? Please like, upvote, mark my answer as best , and see my profile. Thanks for your support!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

  • Create New...

Squarespace Webinars

Free online sessions where you’ll learn the basics and refine your Squarespace skills.

Hire a Designer

Stand out online with the help of an experienced designer or developer.