Convert AVIF to JPG on Mac

Yes, and you can verify it yourself rather than taking anyone’s word for it. ImageIO, the framework behind Preview, Quick Look, Finder and sips, publishes the list of formats it can read and write. On macOS 27.0 (build 26A428) that is 62 readable identifiers and 22 writable ones. One line of Swift prints them:

swift -e 'import ImageIO
print((CGImageDestinationCopyTypeIdentifiers() as! [String]).sorted().joined(separator: "\n"))'

public.avif appears in both lists, so macOS can decode AVIF and encode it. Quick Look confirms the decode side: qlmanage -t -s 256 photo.avif returns “produced one thumbnail”.

One wrinkle worth knowing. Preview’s own Info.plist declares public.avif with the role Viewer, not Editor, the same as HEIC. Preview will happily show you an AVIF; it treats the file as read-only. JPEG, PNG, TIFF and PDF are the four types it declares as Editor.

So when something “chokes on AVIF” on a modern Mac, it is almost never macOS. It is one specific app that predates 2023, or an upload form with a hardcoded MIME allow-list. Which of the two it is matters, because one of them has a better fix than converting.

Here is the chain, measured on image 23 of the Kodak lossless suite, a 768 × 512 photograph. The original PNG is the reference every row is scored against, using PSNR in decibels, where higher is better and a difference under about 0.5 dB is invisible.

Read the last column down and the ceiling is obvious. The AVIF measured 36.86 dB against the original. No JPEG made from that AVIF ever beats it: quality 95 reaches 36.73 dB and stops. Pushing from q85 to q95 spends 7,898 extra bytes to buy 0.10 dB, which is nothing. You cannot recover what the first encoder already discarded, and paying for a higher JPEG quality only preserves the AVIF’s artifacts more faithfully.

The comparison that shows the real damage is against a JPEG made from the original instead of from the AVIF.

That gap is the generation you lost. If the original still exists somewhere, export the JPEG from it and delete the AVIF from the workflow entirely. This is the same argument made at greater length in converting HEIC to PNG, where the numbers run in the other direction but the principle is identical: pick the target from the source, not from whatever intermediate you happen to be holding.

AVIF is roughly twice as efficient as JPEG at the same visual quality, so undoing it costs bytes by definition. For photographs the penalty is a factor of four or five. For anything with flat colour and hard edges it is much worse, because JPEG’s discrete cosine transform is the wrong tool for a straight line.

Three content types, each encoded to AVIF at the same setting and then converted to JPEG at quality 85:

Look at the last row twice. The diagram started as a 69,383-byte lossless PNG. After a round trip through AVIF and out to JPEG it is 158,491 bytes, which is 2.3 times the size of the lossless original it was supposed to be a compressed copy of, and it now has ringing around every edge.

Converting to PNG instead does not rescue you either. The same three AVIFs decoded to PNG came out at 440,368, 131,936 and 145,276 bytes. Once an image has been through a lossy codec, PNG faithfully stores the artifacts too, and artifacts do not compress. For the screenshot that is still 1.28 times the size of the original PNG.

The honest conclusion: if the AVIF opens where you need it to open, leave it alone. The conversion is a downgrade in both axes at once.

There are four real cases, and they are worth separating because two have better fixes.

An upload form rejects the file. Job portals, insurance claims, print labs and older content management systems commonly accept only JPEG and PNG. There is no argument to be had with a server-side allow-list. Convert, and accept the cost.

Software older than 2023 has to open it. Adobe added AVIF reading in the 2023 releases; plenty of installed copies are older. Same for older versions of Affinity, most scientific imaging tools, and effectively every embedded viewer. Convert.

Someone on another platform needs it. Check first. Windows 11 ships AVIF support and current Chrome, Edge, Firefox and Safari all decode it, so this reason has expired for most recipients.

You are feeding a pipeline that only speaks JPEG. Legitimate, and the one case where the file-size penalty genuinely does not matter, because the JPEG is an intermediate that gets deleted.

Notice what is missing from that list: “to make the file smaller”. If that is the goal you want the opposite operation. Keep the AVIF, or read how image compression on a Mac actually works before converting anything.

sips has no batch mode of its own, but it does not need one. A shell loop covers it, and the formatOptions flag sets JPEG quality from 1 to 100:

cd ~/path/to/avifs
for f in *.avif; do
  sips -s format jpeg -s formatOptions 85 "$f" --out "${f%.avif}.jpg"
done

One detail that shows up in exiftool: sips writes JPEG with 4:2:0 chroma subsampling, which throws away three quarters of the colour resolution on top of everything else. For photographs nobody sees it. For a screenshot with coloured text on a coloured background it is visible, and it is not adjustable from sips.

Smol takes the same folder by drag and drop or through its Finder Quick Action, and writes 4:4:4 JPEG with no chroma subsampling. Three AVIFs converted in 575 ms on the M2 Pro, pixel dimensions preserved. What it reported is the reason this section exists:

Negative savings, flagged. A converter that quietly hands back a file five times larger without saying so is doing you no favours, and this is the number to check before you run the same job across a thousand files.

If this conversion is part of a repeatable build step rather than a one-off, Smol also exposes the whole conversion surface over an MCP server that Claude Code, Codex and Google Antigravity can drive directly. Every measurement in this article was produced that way, by asking the app to convert a list of absolute paths and reading back the byte counts it returned.

For one AVIF, use sips. It is already on your Mac, it is a single line, and paying for software to run one command would be daft. For a handful of files, the shell loop above is thirty seconds of typing and costs nothing.

If you need to control AVIF encoding rather than escape it, sips and Smol are both too blunt. avifenc from libavif exposes speed, tiling, chroma sampling and per-plane quality, and it is a brew install libavif away.

If the AVIF is a still frame you actually want as a document rather than an image, the route is different again and is covered in PDF and image conversion on Mac.

Smol earns its place on the fourth case only: a recurring folder of mixed formats that has to come out as JPEG at a consistent quality, with metadata stripped, from Finder, without uploading client work to a website. That is a different job from “open this one file”, and it is worth being clear about which one you have. If it is the recurring one, Smol is $29 once and never sends a byte off the machine.

Related routes: PNG to WebP, GIF to MP4, and the full format reference for every conversion Smol supports.