Mass convert cover art from png to jpg

I have about 7500 audio files with PNG cover art. JPG takes up less space, so I want to convert all the cover art to JPG without doing it manually (this would take forever). I don't want to import from a server, I want the exact album art already present, but converted to JPG within the metadata. I am not trying to extract the files, just convert the metadata image file to another format. Is this possible with MP3Tag?

MP3Tag cannot convert embedded covers to another format. You have to export the files, convert them to JPG with another piece of software and import the files again. This has not to be done manually. Mp3Tag has actions to batch-export (Export cover to file) and batch-import (Import cover from file). For batch-converting pngs to jpgs there are numerous programs like Irfanview.

This is not quite correct.
An action of the type "Adjust cover"

can convert embedded covers from the format jpg to png or png to jpg.
It can also crop the size and quality.

I would run such an action only on the files that really "need" a conversion - so a filter would be useful:
%_cover_mimetype% HAS png

Sorry for my misleading answer. As my workflow includes batch-converting cover-files externally per Mp3Tag-tools for more than a decade I forgot about this newer possible way.

Don't forget to deal with the padding that may be left.
If you don't, the file size may not be reduced as much as you expect.

I think you have to differentiate between Mp3s and Flacs when it comes to audio files.
So far I haven't noticed any significant padding when shrinking embedded covers in MP3s.

Another factor could be the cluster size of the storage device.
If that is bigger than 1 MB, then shrinking a cover from e.g. 490KB png to 136KB jpg will not set free a lot of disk space.
It may happen in some cases when the cluster boundary was only just exceeded that the file would then occupy 1 cluster less ... but just as often nothing would be noticable.
Processing

would increase the wear&tear on the storage, though.

This is exactly what I was looking for, thank you