First check browser support AND the network tab: open the image in a recent browser (Chrome, Firefox, Edge and Safari 16+ all support AVIF), then check the actual Content-Type received in your dev tools' Network tab. An old browser or a compatibility mode may legitimately receive the JPEG fallback without it being a bug.
Next, check that the spot in question is actually covered by automatic replacement: not every preset family is necessarily checked in the settings. An image manually inserted into a post or page, not via the ImagePipe Gutenberg block, never goes through automatic replacement and stays in its original format, which is expected behavior, not a malfunction.
Check the cache: an image visited for the first time before automatic replacement was enabled stays served from its old URL until the page is reloaded with the new rendering. Clear the page cache (if a caching plugin runs alongside ImagePipe) before concluding there's an ImagePipe-side issue.
If none of this explains the behavior: check whether the PHP GD or Imagick extension installed on your hosting actually supports AVIF encoding. Unlike reading, AVIF encoding requires a recent version of the underlying library, not systematically present on every shared hosting plan. In that case, ImagePipe automatically falls back to WebP then JPEG, with no visible error, exactly as intended by format negotiation.