Skip to main content

f_auto is not giving optimum picture format (PNG as standard)



  • Itay Taragano
    1. On what browser were you trying this?

      Note that WebP is only supported on Chrome, Opera and Native Android apps (, that's why f_auto detects the end-user's browser, and then delivers the best format possible, based on the browser's supported formats.

    2. You've got f_auto defined twice in your URL, while there isn't a real issue by doing so, it's redundant.
    3. We have additional optimization algorithms that run when you combine both q_auto and f_auto. So when accessing this image from a non-webp-supported browser (e.g., FireFox), Cloudinary will perform some further detections. For example, our algorithms detected that you can get the same visual quality for this image with JPG which is considerably more efficient (file-size-wise) than PNG.

    I hope this makes sense.


  • Carl-Erik Kopseng

    @Itay, no that does not make very much sense.

    It should deliver whatever format is best suitable for any given browser. It does not. It delivers a 10x as big PNG file on Safari as the JPEG it delivers if I specify q=auto. If I am on a non-webp supporting then of course it should deliver whatever is the second best thing, be it jpgxhr or something else.

    What strikes me as a bug is that using q=auto will give me the best file format for the browser, whereas q=50 will disable the logic for choosing the best format and simply give me a quarter megabyte image. It might be that having a quality setting does not make much sense on a PNG image, but in that case it should only apply any quality settings if applicable when the auto-negatiated format is suitable. At no point should I be given a png for a normal photo. Illustrations, yes.

  • Itay Taragano

    Thank you for your response Carl.

    Please allow me to clarify a little bit about the different features here.

    When f_auto is used (without q_auto), then it'll deliver either one of the following 3 formats: WebP (only if on Chrome/Opera/Android), JPEG-XR (only if on IE/Edge), and a 3rd format for all other browsers (e.g., FireFox, Safari, and others). The 3rd format will be either the one that is specified in the extension part of the URL, or if no extension is defined (like in your example), then we'll deliver the original file's format, which is in this case, a PNG.

    On non-webp and non-jpeg-xr supported browsers (e.g., FireFox/Safari), where the 3rd format is delivered, then if it's a PNG (like in this case), then q_50 is actually being ignored and doesn't do a thing, because PNG is a lossless format and doesn't support quality compression, q_50 will come into effect only on WebP and JPEG-XR which are both lossy formats.

    The combination of both f_auto and q_auto took this to the next level, this extends the feature and offers the ultimately best possible format, so on FireFox and Safari, a JPG image is delivered for this case.

    I hope this clarifies a bit.

  • Carl-Erik Kopseng

    Yes, that does clarify matters. I only wish this algorithm was explicitly documented. I can't think of many reasons why I would ever want to have a larger file format, but I do understand that falling back to the original at least will not choose a file type that will give a worse quality for the content type (png being optimal for most illustrations, jpeg for photos).

    How does f_auto, q_50 and explicit file endings, such as ".jpg", work together? Does this mean I get the best of both worlds? Meaning best supported format due to f_auto and fallback to ".jpg" for Safari & co. Or will this always enforce jpg?

    What I would like to achieve is what I pictured above: webp or jpeg-xr if supported, else fallback to some user-defined default with a given quality setting.

  • Itay Taragano

    In that case, then yes. Using f_auto and including an extension (e.g., ".jpg") will indeed deliver:

    • WebP (on Chrome/Opera/Android)
    • JPEG-XR (on IE/Edge)
    • and JPG all other browsers (e.g., FireFox, Safari).

    Including q_50 will compress to 50% quality on all of these options (formats).

    In addition, note that:

    • As you said, there are cases, like with illustrations, where PNG may be more optimal than JPG.
    • If the original image includes transparency, then you may want to deliver a PNG instead of a JPG (since JPG doesn't support transparency).
    • q_50 may look differently on the different formats and different images.

    That's why using q_auto instead (including its different profiles) will answer all of these challenges. It'll automatically detect the cases where PNG may be more optimal than JPGs, it'll make sure that if the original image is transparent - we'll deliver a PNG, and JPG otherwise, and it'll make sure that the most optimal quality is defined, as it's detected for every image and every format individually.


Post is closed for comments.