Hi Forum 
Before Umbraco 17 we didn’t use HMACSecretKey, so we didn’t have a problem using a WebP Middleware which automatically checked if WebP was supported and appended the “format=webp” if it was.
But this is not the case anymore
So we have begun using HMACSecretKey, but of course this will "alter” the URL after the HMAC has done it’s magic and then invalidating the Image URL.
How have you solved it the “issue” with serving WebP and using HMAC?
hi Anders,
I have a webp middleware and HMAC on 17 and I haven’t seen the issue, Umbraco passes the secret to ImageSharp.Web so everything is calculated at the correct time, at least in my experience.
Matt
Sounds good
Mine just won’t render the images and i keep getting errors in the console.
Can i ask how you done it or to post your middleware?
Sure thing
Composer
services.Configure<ImageSharpMiddlewareOptions>(options =>
{
// Capture existing task to not overwrite it
var onParseCommandsAsync = options.OnParseCommandsAsync;
options.OnParseCommandsAsync = async context =>
{
ImageProcessing.ConvertImageToWebP(context);
ImageProcessing.PreventUpscaling(context);
await onParseCommandsAsync(context);
};
});
internal static void ConvertImageToWebP(ImageCommandContext context)
{
if (IsWebpAbleImagePath(context.Context.Request.Path) == false) return;
var acceptWebP = context.Context.Request.GetTypedHeaders().Accept.Any(aValue => aValue.MediaType.Value == WebpFormat.Instance.DefaultMimeType);
if (acceptWebP == false) return;
if (!context.Commands.Contains("format"))
{
context.Commands.Add("format", "webp");
}
if (!context.Commands.Contains("quality"))
{
context.Commands.Add("quality", "80");
}
}
Results in <image-url>.png?rmode=pad&width=550&hmac=23b297fd0fa92a4937add52888355c85999d82a9f0b756d6f30e510393835c37
have you tried clearing your image cache, if ImageSharp already had images in the cache that might cause it?
I’m still having issues with images not showing on the frontend and Umbraco 
Yeah i have deleted the whole temp folder aswell ..
Webp support is widespread, so honestly, we only serve webp images these days.
However, if you want to support non-webp browsers, why don’t you simply create an image source set in the html with multiple formats? I agree that the html will get a little bigger, but you let the browser decide what it supports and what the correct size is that is needs. That saves on middleware processing time.
FWIW @AndersBrohus , I was working on this exact task just yesterday and was experiencing the same results.
We started out a new project on 17.1
We’re now on 17.2.2 and always convert all of our images to .webp
I followed the imaging settings documentation and all the images resulted in a 404.
I finally reverted the effort because i didn’t get to a timely victory, sigh!
Of note - it did not occur to me to try any other image formats so I didn’t think it was an .webp issue specifically.
Started seeing a similar issue myself now but its fine if the image is using GetCropUrl(…) so all the media based images are happy, however just a url with no crops or querystring I hit the issue as the HMAC querystring is missing
I know nothing. But given the approach above, I ran into the same issue. Once you apply formatting commands, I suspect a HMAC is required. i.e., a request with no image-crop commands has no HMAC, but once you apply a command, an HMAC (and a valid one) is required.
Thanks to this discussion, I realized that my AutoFormatImagesToWebp package didn’t support the HMACSecretKey setting. I’ve released a new version that should fix this issue, but I need feedback from someone who isn’t using my machine!
(There’s a little more happening in my package that may not make it suitable for everybody.)
This ended up been for images that were not be called by GetCropUrl() added a to my vite config and static images and the middleware works as before