Support » Fixing WordPress » Unable to Disable Image Compression

  • Hi,

    I know this topic has been covered many times before but after reading several threads on the forums and multiple blog posts offering solutions, I’m still unable to stop WordPress from performing lossy compression when resizing images.

    I’m building a photography website so it’s important that I’m able to control the quality of my images. I apply compression during export from Photoshop so don’t need or want to apply more lossy compression when importing to WordPress because doing so results in obvious artifacts and loss of sharpness.

    I’ve been uploading images double the size of their containers for retina displays so relying on WordPress to resize the 2x images to half that size to fit the containers. The resulting images are quite soft as you can see in the image at the bottom of the page (the second image):

    I’m not using any caching plugins (that I’m aware of).

    To disable the native compression, I’ve tried adding several variations of the following “add_filter” code to the php file using the Code Snippets plugin. No luck there.

    add_filter(‘jpeg_quality’, function($arg){return 100;});

    I’ve also tried using the Image Quality plugin to change compression quality to 100 in Media Settings. That didn’t change anything. (By the way, it’d be great if WordPress made that an option natively, considering how many people are struggling with this!)

    I’ve even read that installing Optimole just to turn off the WordPress native compression is a possible solution. That also didn’t work.

    The only workaround I see now is to upload separate images for retina displays and normal resolution displays (images at half that size).

    Hopefully instead of doing that, someone can point out a workable solution with a snippet of code or a plugin that will work.

    Thanks in advance for any suggestions!

    The page I need help with: [log in to see the link]

Viewing 11 replies - 1 through 11 (of 11 total)
  • Hi @afmeckel, thanks for doing your homework here and putting so much work in to fix this. Quick question—are you uploading new images each time you test your changes? Just as a reminder, you likely know this, disabling compression will only effect images uploaded after its been disabled, not already-uploaded images.

    For existing images you need to use a plugin that regenerates thumbnail, for example:

    There’s one other thought I have. It’s possible your theme or an other plugin is altering image quality on it’s own, and their script is higher priority than yours. You could try something like this in your snippets plugin:

    function custom_jpeg_quality( $quality, $context ) {
    	return 100;
    add_filter( 'jpeg_quality', 'custom_jpeg_quality', 10, 2 );

    where you alter the “priority” parameter (in this example, the number “10”). You can learn a bit more about that here:

    Last thing—have you confirmed that the “Code Snippets” plugin is successfully adding code? You could test it with a silly example like this (note that this code would show an alert box to *all* logged-in users on your site:

    function add_alert() {
    		if (! is_user_logged_in() ) return;
                alert('Code ran successfully');
    add_action('wp_head', 'add_alert');

    with the following result:

    CleanShot 2021 03 22 at 13 26 34 2x

    Thread Starter afmeck


    Hi Zack,

    Thanks for the quick response and suggestions!

    If there’s one thing I’ve learned as non-coder working with WordPress, it’s to do my homework. 🙂

    Yes, I’m uploading a new image every time I test (or rather re-uploading the same image) after deleting the old one from the Media Library and making sure it’s gone from the uploads folder with an FTP client. And also clearing both the WP and browser caches before uploading a new image, just in case.

    Fortunately, I’m only working with new images as this is a brand new site so I’m not having to regenerate thumbnails yet.

    I tested the Code Snippets plugin with your example snippet and did get the success message.

    I also noticed that Code Snippets provides a “Priority” field for each snippet that’s set to 10 by default. I assume that’s the same functionality as the priority snippet you provided?

    To be honest, though, my non-coding brain isn’t quite getting how that works. To test it out, should I assign a lower value to the priority? Or should I try entering a value greater than 10? And if I paste that snippet into Code Snippets will the plugin just override it with the default Priority value?

    Alternatively, I can also just add the snippet to the php file manually since I’m using a child theme.

    What do you suggest?

    Thanks again!

    I can qualify priority more 🙂 And yes, I’d say try putting the snippet in the functions.php file of your child theme.

    Regarding priority, given the following examples:

    function set_title_2( $title )
    	return 'hello2';
    add_filter( 'pre_get_document_title', 'set_title_2' , 15 );
    function set_title( $title )
    	return 'hello';
    add_filter( 'pre_get_document_title', 'set_title' , 11 );


    A filter with priority 15 runs *after* priority 11, so the page title would become ‘hello2’. You could try a priority with a high number, maybe 50 or so, to ensure that your image quality priority code runs last.

    Thread Starter afmeck


    I see how that works now. Thanks for clearing up the priority function.

    Out of curiosity (and due to an irrational fear of breaking my site), rather than entering the snippet directly into the php file as you suggested, I tried increasing the priority to 50 in the Code Snippets plugin and ran another test.

    The result is the opposite of what I expected: The artifacts around the edges of objects in the image are gone but the image is still soft. Even more surprising, the resized image’s file size is several times bigger than the original image with the same dimensions.

    In other words, the first image on the page is not resized at all (675 x 507) and weighs 74kb. After increasing priority, the second image (resized at half it’s original size of 1350 x 1013) weighs-in at 292kb. That’s even bigger than the original 1350 x 1013px image that weighs 219kb.

    I’m not sure why the image is still soft but obviously I can’t use this method anyway if it results in such an increase in file size.

    I can still try manually adding the priority snippet but I assume it would have the same effect, right?

    Any idea what’s going on?

    Perhaps I should bring this up with the theme developer, too?

    Hi @afmeckel it looks like you did successfully disable image compression.

    The second image here: is 1350x1013px (displaying as 675 x 507 due to the width of the theme) and showing as 221kb. That sounds like it matches the specs of your original image!

    The purpose of compression is to make a sacrifice of quality in exchange for image size. Something you could try is manually compressing your images yourself, before uploading to WordPress with compression disabled. You could try a tool like and see how the quality of their compression compares to WordPress.

    You could also look at resizing the images without compressing them, to reduce the filesize, since it appears with your theme they will never display larger than 675px wide.

    Otherwise, you could look into sharpening/editing the photos in photo editing software yourself.

    Thread Starter afmeck


    Yeah, apparently compression has been disabled so thanks for that!

    What I’m wondering now is why has disabling compression resulted in a big increase in file size from the originals? In this case, an image that’s half the size of the original becoming almost 50% larger and still appearing soft.

    And again, the original un-resized 675 x 507 image that appears at the top of my test page (edited, sharpened and compressed with a quality of 75% in Photoshop) is only 74kb.

    The second (softer) image, resized by WordPress from it’s 1350 x 1013 original to 675 x 507, is 292kb.

    Why would disabling compression result in such a huge increase in size? As you pointed out, even the original 1350 x 1013 image that it’s derived from is only 220kb.

    Like I said, I’m already doing my sharpening and compression in Photoshop so I’m not interested in applying anymore lossy compression with another application.

    I really appreciate the effort you’ve made to solve this but unfortunately it seems the solution has just created another problem.

    I suppose I need to start a new thread asking why turning off compression results in much larger file sizes?

    You may have missed this from my last post—I’m not seeing a 291kb image anywhere. I’m seeing 221kb for the second image:

    Images *can* get +/- 5kb size differences on upload, but that doesn’t seem to be happening here.

    It’s very likely everything is working perfectly!

    Last point—WordPress isn’t creating a 675 x 507 221kb image, rather a 1350 x 1013 221kb image is being displayed at 675 x 507. The actual image file sent to users is the full size, but the styling of the theme causes it to display only 675px wide.

    • This reply was modified 4 months, 2 weeks ago by Zack Krida. Reason: clarification
    Thread Starter afmeck


    That’s interesting. I have to wonder why WordPress is even serving the original full-sized image when it’s also creating the half-sized image at the size I set in the Media Settings.

    Since I haven’t found an option in the Gutenberg builder to choose that size for inserting into a block I assumed WordPress would automatically serve it according the container width. Guess I was wrong.

    Here’s a screenshot of my uploads folder with the file sizes I mentioned:

    Anyway, it’s looking like probably the easiest way to get control over image quality in this case is to upload separate files sized for regular and retina displays.

    Thanks for your time.

    Thread Starter afmeck


    The link wasn’t added in the previous post:

    Thread Starter afmeck


    Well, that’s embarrassing. I guess I don’t know how to use the link function.

    Third and final try:

    FTP client screenshot

    No worries about the link editor. It looks like you removed the Mount Hood images
    from the site, but I’m actually suspicious that your ftp client was giving incorrect size values, which isn’t as wild as it might sound. I’ve seen that issue in the past.

    Anyway, feel free to mark this ticket as ‘resolved’, since we took care of the core problem, otherwise feel free to follow up with more questions. Thanks for all your work @afmeckel !

Viewing 11 replies - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.