Experimenting with WordPress Image Sizes

As a general rule, it’s a good idea to keep images as small as possible because loading large images will slow a site down.

However, they should never be uploaded with a smaller size, in pixels, than the size at which they will be displayed. For example, if an image is 600px wide but it is enlarged to stretch across the full width of the screen then it will look terrible.

The difficulty is that you need to balance “as small as possible” with your desire to display high quality images and you should take into account the purpose of the image. It will be important that the images in a photographer’s portfolio look fantastic, but if all you are doing is using a picture of a sundial to illustrate a blog post on time managment, then you may not be so fussy.

Various Image Sizes Created by WordPress

When an image is uploaded to WordPress, various smaller versions of it are created. The sizes of the Thumbnail, Medium and Large images are determined in the Dashboard under Settings > Media.

When editing a post and inserting an image, you’ll be given the option of choosing one of these smaller sizes or using the full size image.

Depending on the size of the image that is uploaded, images with sizes of 768px, 1536px, 2048px and 2560px may also be created to be used with the scrset HTML attribute.

A relatively recent change, intended to stop people slowing down their websites with massive images, means that you can no longer insert a full size image that is larger than 2560px. The big 2560px image that WordPress created will be used instead.

Because most people will need their sites to load quickly, when creating the different sized images WordPress uses a compression factor of 82%. I don’t always want it to do this, so sometimes use the Code Snippets plugin to add the filter below which increases this value to 95% (Previously, I’ve found that using 100% resulted in images that were even larger than my original upload.)

add_filter('jpeg_quality', function($arg){return 95;});

Choosing an Image That is Neither Too Small Nor Too Large

For this exercise, I’m using a photograph of a watch by Bru-nO from the free microstock site Pixabay.com. This is available in various sizes, and picking the most appropriate one already goes some way towards making sure my website will not be bogged down by an enormous image. As you’d expect, the image that is widest in terms of pixels is also largest in terms of kB.

I downloaded the 1920, 1280 and 640px wide versions of the image and added them as background images to full width containers below, with the largest image first. The smaller image has been upsized from 640px to 1920px (on my desktop monitor). This is not something I’d usually do.

On my 1920px wide desktop monitor the larger two versions of the image look sharper than the smallest one. The top one, which does not have to be enlarged to fit the space, is the sharpest of all.

When I look at this article on a screen which has higher pixel density than my PC monitor (e.g. a phone or an ipad) the varying quality between the images becomes more visible.

The biggest image is rather larger (in terms of kB) than I would usually be happy with. I’d normally want to optimise it to stop it slowing down the page loading time.

Optimising an Image

The 1920px wide image that I used in the section above was 341kB when I downloaded it from Pixabay (I’m not sure why Pixabay told me it would be 550kB as this didn’t turn out to be the case). I used it just as it was in the section above, but usually I try to make sure that images are no more than 250kB to 300kB, as a rule of thumb.

In some cases, I might not worry too much if a full width (1920px to 2560px wide) hero image was a bit bigger than 300kB, but generally it’s best to go with the smallest possible image that still looks good (which is subjective). Even 300kB might be considered to be too large.

There are several plugins that will optimise images as they are uploaded to WordPress, but I prefer to optimise them myself first. I like to use the free online https://kraken.io/web-interface or http://webresizer.com/resizer/. Another good option would be https://shortpixel.com/online-image-compression.

Optimising the large photo of a watch with Kraken only reduced its size from 341kB to 332kB so I would guess that Pixabay had already applied their own optimisation.

In this case, I turned to ShortPixel as their tool offers 3 levels of compression; lossy, glossy and lossless. When I tried to apply the lossless level to the watch photo I was told it was already optimised.

Shortpixel’s glossy compression resulted in an image that was 206kB and looked pretty good – see below.

The lossy compression gave an image only 94kB big. If I carefully compare the two images I can just about see that the first is a little better, but the quality of the second may well be acceptable.

Exact Size or Twice the Width?

In the sections above, I used the various sizes of the watch photo as background images, with a background property of “cover” which meant that the small one was upsized to fit its container. If photos are added as Image Blocks, rather than as background images, then they should be displayed at the size they have been uploaded, or downsized if they are too big to fit the space.

In the past I’ve usually uploaded images that are exactly the size (in pixels) as the space they will occupy (e.g. an 800px wide image to fit in an 800px wide space on the page). However, there’s a school of thought that suggests uploading images that are twice this width to account for high resolution screens, such as Apple retina displays. In this article, I’m going to experiment to see what happens when I do this.

I’m planning to display the photo as an 800px wide image, so I’m going to create two versions; an 800px wide one and a 1600px wide one.

I used Capture One software to edit a photo I had taken using and saved it at 1600px wide with a quality setting of 75, to get it down towards the sort of size I am happy with. This resulted in an image of 380kB.

I optimised this with Kraken’s online tool and obtained the image below, which has a size of 248kB. Note that the image was uploaded at 1600px but I’m displaying it in an 800px wide container.

Image A – uploaded as 1600px wide

I usually go through this two stage process, because I like the results obtained by Kraken’s algorithm, but I realise that I am making work for myself. You might wonder why I don’t just use a lower quality setting in the photo editing software. I found that to reduce my image to the same sort of size that Kraken achieved, I needed to use a quality setting of 50, rather than 75, in this case. I felt that my two step process resulted in an image that looked infinitesimally better. I’ll probably stick with the method I’m happy with but wouldn’t necessarily suggest that you do the same, as it may not be worth the extra effort.

I’ve chosen to display the full size image above. WordPress has also created a “large” image which is 800px wide as I mentioned at the start of this article (note that, as I explained before, I am using a filter so that this is less compressed than the default). Just for completeness, here’s what that WordPress created image version looks like. This is only 67kB in size.

Image B – the “large” image created by WordPress from my 1600px wide photo

I wanted to compare the photo that I uploaded as 1600px to one which I uploaded as 800px (not the large one created by WordPress but my own, pre-sized and optimised version).

There are two ways I could approach this. When editing my photo in Capture One and saving it as an 800px wide image, I could use the same quality level (75) as I did for the 1600px wide image which should give me a smaller, faster loading, image than the 1600px one.

Image C – 800px wide saved with Capture One quality level 75 then optimised with Kraken

The 75 quality image ended up as 78kB after processing with Kraken.

Alternatively, I could take the view that I can get an acceptably small (in kB) image with a higher quality level for an 800px wide image compared to a 1600px wide one. For the sake of completeness, I decided to try both approaches.

Image D – 800px wide saved with Capture One quality level 95 then optimised with Kraken

The 95 quality level image above is 93kB.

To my eye, on my standard 1920px wide monitor, the image that was uploaded at 1600px wide (image A) may be very, very slightly better than the ones that were uploaded as 800px wide (images C and D). I doubt I would really notice any difference though and I’m not sure the increase in size ( 248kB compared to 78kB and 93kB) would be a fair trade off. If I compare them directly and stare hard I could maybe find a few areas where image C looks a little worse than image D. But they are almost indistinguishable.

The Large Image size created by WordPress (image B above) does look a bit less sharply focused, duller and with less contrast than the others. I would expect the difference to be even more marked if I had not used the code snippet mentioned towards the top of this article.

On the ipad screen, it was easy to see a difference in quality between image A (uploaded as 1600px wide) and images C and D (uploaded as 800px wide). In cases where image quality is very important, it might be worth considering uploading a double width photo.

What surprised me, was that image B looked better on the ipad screen than images C and D did. For image B, I had chosen to use the “large” image created by WordPress, rather than the full-sized image. It turned out to be the case (at least with the GeneratePress and Twenty Twenty themes) that the scrset attritbute was being used to display the 1600px wide image instead.

The scrset Attribute

Where a theme developer has chosen to make use of it, the scrset attribute is used to display an appropriate sized version of an image depending on the size and pixel density of the screen.

If you are reading this article on a smaller screen than my 1920px wide monitor, a laptop for instance, then you may wonder what on earth I have been talking about. For you, images A, B, C and D in the section above might look identical. You may be seeing the 768px wide “medium_large” image created by WordPress for them all. Like the “large” image discussed above, this image has been compressed and is lower quality than the ones I have carefully resized and optimised. So that’s quite annoying!

I can stop WordPress from creating this medium_large image by adding the following using the code snippets plugin (or directly to the functions.php file if I am using a child theme.

function jb_disable_medium_large_images($sizes) {
 unset($sizes['medium_large']); // disable 768px size images return $sizes;

 add_filter('intermediate_image_sizes_advanced', 'jb_disable_medium_large_images');

I used this filter and uploaded another copy of the 800px wide image (the same as the one used as Image C above). The quality of this version, when viewed on a small, non-high density screen, should be higher than the versions above.

There is also a plugin, Disable Media Sizes, that can be used instead of adding the code yourself.

The Perfect Images + Retina Plugin

Having carried out the various experiments described above, I am left with a dilemma. If I particularly want a certain photo to be displayed at a high quality then I can upload it with twice the width I’ve set for its container. But that will be unnecessarily large for visitors who do not have an extra large or high density screen. If I upload the bigger image and choose the “large” image setting when I add it to an image block, then the srcset attribute will mean that the high quality version will be shown to those viewers with high density screens, but other visitors will see the lacklustre version created by WordPress.

The well known Perfect Images + Retina plugin (formerly called “WP Retina 2x”) by Jordy Meow could be the solution. There is a tutorial for the plugin on the Meow Apps website.

Having installed and activated the plugin, I consulted the tutorial and changed the plugin settings in my WordPress dashboard. I could get rid of the code snippet I’d used earlier to stop WordPress creating the medium_large image, as the plugin includes that feature.

I chose not to get the plugin to automatically generate retina images because I decided to upload my own resized and optimised images whenever I felt this was required.

To test that the plugin was working as expected, I used a photo I’d taken on the same day as my previous example. I uploaded an 800px wide version called meowtest.jpg and a 1600px wide one called meowtest@2x.jpg.

When I inspect the CSS I can see the code below:

<img loading="lazy" src="https://janebwebsitehelp.co.uk/wp-content/uploads/2021/01/meowtest.jpg" alt="" class="wp-image-5631" srcset="https://janebwebsitehelp.co.uk/wp-content/uploads/2021/01/meowtest.jpg 800w, https://janebwebsitehelp.co.uk/wp-content/uploads/2021/01/meowtest-400x267.jpg 400w, https://janebwebsitehelp.co.uk/wp-content/uploads/2021/01/meowtest-200x133.jpg 200w, https://janebwebsitehelp.co.uk/wp-content/uploads/2021/01/meowtest@2x.jpg 1600w" sizes="(max-width: 800px) 100vw, 800px" width="800" height="533">

I had disabled the medium_large size but on extremely small phone screens, for example, the srcset attribute should mean that my 400px (as set in my Dashboard) medium image is used. That seems fine to me.

Just for fun, to make it easier to see what was happening I uploaded two more images; an 800px wide photo of a labrador (by Chiemsee2016 at Pixabay) called dog-image.jpg and a 1600px wide photo of a st bernard (by vlaaitje at Pixabay) called dog-image@2x.jpg. If you are viewing this article on an extra large screen, or one with a high pixel density, then you should see the st bernard below. Otherwise it should be the labrador, but if you zoom in then the picture should change.


For a thorough explanation of the different image file types see: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types

I tend to use jpg’s for photographs as they can often be smaller than the corresponding png files. However, I’ll use a png if the image contains text, or straight lines etc.

From the article above:

The JPEG (typically pronounced “jay-peg”) image format is currently the most widely used lossy compression format for still images. It’s particulary useful for photographs; applying lossy compression to content requiring sharpness, like diagrams or charts, can produce unsatisfactory results.

PNG is preferred over JPEG for more precise reproduction of source images, or when transparency is needed.

SVG files are text files containing source code that, when interpreted, draws the desired image. SVG files are ideal for diagrams, icons, and other images which can be accurately drawn at any size.

There are times when it can be useful to have transparent areas in an image. Here’s a screen shot of a png file in Paintshop Pro. If this was saved as a jpg then the transparency would be lost, as can be seen when I put both versions on top of a paper background from https://www.toptal.com/designers/subtlepatterns/


For most photographs and illustrations, I’ll use either a jpg or png file but recently I’m seeing svg files being used more frequently than before. These are vector files that are made up of lines and shapes, as you can see in the screen print below. They can be displayed at any size without becoming pixellated or blurred.

It’s possible to find svg files from the same kind of sources as other images but, in this case, I opened an eps file in Affinity Designer and then exported it as an svg.

Some plugins (e.g. GenerateBlocks and Kadence Blocks) include svg icons and shapes. GenerateBlocks also allows you to use your own.

But if you want to upload svg files to your media library then you’ll need to use a plugin such as Safe SVG. I have already installed and activated that plugin, because I am using an svg for my logo on this website.

As with the other file types, there is a free online optimiser for svg files. This is at https://jakearchibald.github.io/svgomg/. In the case of my butterfly, it didn’t reduce the file size very much so I just kept the file I’d exported from Affinity Designer.

However much you zoom in, the butterfly image above should look fine.


There’s a reason that this article is entitled “Experimenting with WordPress Image Sizes” rather than “A Definitive Guide to Image Sizes”. I’m not claiming to be an expert in this area and there are several issues that I have not touched on – for example plugins that optimise images within WordPress, Content Delivery Networks (CDN’s) or the WebP image format.

I wanted to do a few experiments on the subject of how WordPress handles images, so that I can make sure that I have a few rules of thumb that I am happy with. What I have concluded is as follows:

  • I have confirmed that it’s not a good idea to display images at a larger size in pixels than the size at which they were uploaded.
  • I think I could optimise images a bit more aggressively than I have tended to do in the past.
  • Uploading images that are twice the size they are displayed on my PC monitor does seem to result in a slightly better looking result on high density screens. Whether or not it’s worth doing this will depend on the purpose of the image.
  • Not using a double sized image doesn’t necessarily lead to terrible looking images on ipads and the like. There’s no need to panic and replace every image on my website with a bigger version.
  • The The Perfect Images + Retina plugin does appear to work in cases when I do want to add a larger version to the srcset attribute. It does not affect background images.
  • This plugin can also be used to prevent WordPress from creating unnecessary image sizes, or I could use a code snippet for that.

More Tutorials

1 thought on “Experimenting with WordPress Image Sizes”

Leave a comment