Hi Omar,

for me, your file has the same issue I described in my original post.

I attached your file again after saving it on my system, maybe there is some difference between the two versions (your upload and mine) that causes this issue.

I'll also try to replicate this on my old laptop later. That laptop runs on Linux Mint and has an integrated GPU, so it shouldn't be quite different in that sense.
Edit: I tried on my Linux laptop now with Omar's file, but it also gave me the same result: It shows the fire as expected inside Blender after rendering, but when I save and open the image, the fire is gone.
Edit2: On my laptop, I have Blender 3.0.0 installed. It runs Linux Mint 20.3 Cinnamon and has an Intel Core i5 2430M with integrated graphics controller.

Are you sure it is just not related to how the application you use to view the image is handling alpha? Some applications don't handle different cases of alpha like premultiplication well. Does the image I attached above get viewed correctly for you or is it just the same?

Here is a screenshot of my saved render (left) vs. your image from above, both opened in the same application. As you can see, the cube in my render has sharp edges, whereas in your image, the fire shows up correctly.

Here is my render, just to check if that is displayed correctly for you.

And here is a full resolution screenshot of that same render in my viewer application

There seems to be a very faint hint of the fire in the image, but it's far less than in Blender.

It may be related to: https://developer.blender.org/T81199

It seems like the image viewer and compositor perform some tone mapping that causes bright transparent values to contribute to the alpha. However, the alpha channel is not modified when saving the image. The same problem happens when using bloom and transparency, particularly when using EEVEE's bloom.

Note that you can save the render as an EXR. Then, when you load the image back into Blender, Blender will reintroduce the tone mapping to the alpha channel and you can use the image in the compositor as expected. Then if you save the composite without alpha, there will not be a discrepancy between Blender's internal image viewer and an external image viewer.

Also, node that if you enable Convert Premultiplied, the alpha is not effected in the same way.

It's the same problem described in T81199: Some effects [bloom, smoke, fire, ..] still don't save in PNG with transparent background (occlusion vs. emission).
Basically, Alpha + Emission + PGN don't get along well together.
That's because an emission like fire, although visible, can still have alpha 0.0, and PNG sees this as invisible.
Maybe the PNG codec needs to be edited to do a correct emission + alpha conversion.

@Germano Cavalcante (mano-wii) I would like to see two additional checkbox options for the PNG RGBA format.

1. Clean Alpha: Set RGB pixels to black if the pixel is fully transparent.
2. Modify Alpha: Modify the alpha channel to correctly represent the image when used as a straight alpha.