In this episode we explore modern image formats: WebP, AVIF, JPEG XL, and HEIC, along with vector formats like SVG and PDF. We'll also dissect the role of delegates — ImageMagick's bridge to external libraries — and how to check format support in your installation.

In episode 11 you aligned colors across devices via ICC profiles and colorspaces. But there's a more fundamental question we haven't answered until now: what format should you use to store your work? PNG and JPEG are the foundations, but they're no longer the only options these days.
Episode 12 opens up the world of modern formats — WebP, AVIF, JPEG XL, and HEIC — plus two formats that often confuse people: SVG and PDF. More importantly, we'll dissect how ImageMagick actually talks to these formats through something called delegates. Understanding delegates answers the classic question everyone has experienced: "why can magick on my machine not read this file, when it works on my friend's machine?"
PNG and JPEG were born in the 1990s, long before bandwidth became cheap. JPEG shrinks size by discarding detail, PNG is lossless but wasteful with space. Modern formats answer these limitations from three directions at once:
This is analogous to storage: PNG and JPEG are cardboard boxes that have existed for a long time, while modern formats are specialized containers — more efficient, but needing the right tools to open them.
WebP was designed by Google for web needs. It supports lossy and lossless in one container, plus alpha channel and animation (a far lighter GIF replacement).
magick input.png -quality 80 output.webpmagick input.png -define webp:lossless=true output.webpThe key is in -define — how ImageMagick hands format-specific parameters over as key-value pairs. For WebP, webp:lossless=true selects the lossless mode, and webp:method=6 forces the encoder to work hardest (and slowest) for the smallest result:
magick input.png -define webp:lossless=true -define webp:method=6 output.webpFor ordinary photos, -quality 80 is usually already indistinguishable from the original to the human eye — and the result is far smaller than JPEG at equivalent quality.
AVIF is the most aggressive format when it comes to size: it uses the AV1 video codec inside a HEIF container. At visually identical quality, AVIF files can be half the size of WebP. This isn't magic — it's the power of AV1, originally designed for video, adopted for still images.
magick input.png -quality 50 output.avifNote that -quality for AVIF is measured against the AV1 encoder scale, so a 50 can already look very good for photos. For finer control, avif:compression-level can be lowered for faster encoding:
magick input.png -define avif:compression-level=8 -quality 60 output.avifAVIF has two real drawbacks: its encoding is slow, and decode support in older applications is still limited. For still images stored once and read many times — the typical CDN case — it's a very strong choice.
JPEG XL is designed to be the "one for all" format: efficient lossless, superior lossy, progressive, no 8-bit limit, and it can even convert old JPEGs without losing quality. Its philosophy differs from AVIF — JXL pursues compatibility and speed, not the most extreme compression.
magick input.png -quality 90 output.jxlmagick input.png -define jxl:lossless=true output.jxlFor personal photo archives, JXL lossless mode is often the best choice: almost half the size of PNG without losing a single pixel. Its downside is ecosystem support that's still evolving — check first whether your target readers can handle it.
HEIC is the native format of iPhones and many Android devices: HEIF wrapped in the HEVC (H.265) codec. You'll often receive these files as phone photo exports, and the question is almost always the same: "how do I convert this to JPEG so I can send it?"
magick input.heic output.pngmagick input.heic -quality 85 output.jpgThe reverse direction — writing HEIC — is also possible, as long as ImageMagick is built with libheif support. This answers the most frequent conversion in media production kitchens: accepting phone photos and feeding them straight into the pipeline.
SVG is a vector format — not a collection of pixels, but drawing instructions that can scale without limits. PDF is a document format whose contents can include text, vectors, and images. Both look like ordinary formats, but neither is ever decoded by ImageMagick itself.
magick -background none -density 150 input.svg output.pngmagick -density 150 input.pdf output.png-density determines the rasterization resolution — this is an important decision. Imagine printing a document: low density produces a small, blurry print when enlarged, high density produces a giant file. For PDF and SVG, -density 150 to 300 is a reasonable starting point, and this is also why SVG/PDF output is never as "clean" as the source — the pixels are decided at rasterization time.
This is the key concept of this episode. ImageMagick doesn't write its own decoders for all 200+ formats. For many formats — especially ones requiring large libraries like libheif, libjxl, librsvg, or ghostscript — it hands the work to a delegate: an external program or library linked at build time, or an external command run according to the instructions in delegates.xml.
The analogy is simple: ImageMagick is a shipping service reseller. It takes your orders, then picks the best courier for each route. Without a courier for a given route, the order is rejected — not because ImageMagick is lazy, but because it's beyond its capability.
The practical consequence is felt immediately across installations: two machines with the same ImageMagick version can behave differently just because of the library packages installed. A .heic file can be readable on one server and rejected on another with the message no decode delegate for this image format — now you know the cause.
Before debugging a failed conversion, check what's available first:
magick -list delegatemagick -list format | grep -i -E 'webp|avif|jxl|heic|svg|pdf'magick -list delegate shows the format-to-commander map, while magick -list format shows the formats genuinely recognized. Also notice the Delegates and Features lines in the magick -version output — that's where you see which modules were linked at build time:
Version: ImageMagick 7.1.1-40 ...
Features: DPC OpenMP
Delegates (built-in): ... fontconfig freetype heic jbig jng jpeg jxl lcms
lqr ltdl lzma openexr png raqm tiff webp xml zlibIf jxl or heic isn't in that list, you need to install the supporting libraries (for example libjxl-tools or libheif on your distribution), then reinstall or rebuild ImageMagick. No magick command can add capabilities that aren't compiled in.
The delegates.xml and policy.xml files live in ImageMagick's configuration directory. You can point to an additional directory via the MAGICK_CONFIGURE_PATH environment variable — useful in containers, where custom configs are often mounted as volumes:
MAGICK_CONFIGURE_PATH=/etc/im-config magick input.heic output.pngMAGICK_CONFIGURE_PATH makes ImageMagick read the custom configuration directory ahead of the default location. These MAGICK_* variables will become a big theme in episode 13, when we lock down global security policy.
Tip
Use magick -list format | grep -i <name> as your first reflex when a file fails to read. Reading this list is faster than guessing the cause — and the answer is usually not "corrupted file", but "delegate missing".
No format wins in every case. A practical guide:
| Need | Choice |
| web: photos | WebP (broad compatibility) |
| web: extreme compression | AVIF |
| lossless archive | JPEG XL |
| Apple ecosystem | HEIC |
| logo/illustration | SVG (vector, scalable) |
| multi-page document | PDF |
The format decision isn't about "the most modern format", but about who will read the result. The world's best encoder is useless if the reader application doesn't recognize the format.
Episode 12 introduced modern formats and the mechanism behind them: WebP for all-purpose web use, AVIF for the most aggressive compression, JPEG XL for efficient lossless archives, HEIC for the Apple ecosystem, plus SVG and PDF as formats rasterized according to density. We also dissected delegates — the layer that lets ImageMagick hand work to external libraries — and how to check your installation's capabilities with magick -list delegate and magick -version.
The core thing to remember: ImageMagick's capabilities don't come from the command line — they come from the libraries behind it. Two machines with the same command can answer differently just because their builds differ.
In the next episode 13 we flip the point of view from "what can be done" to "what is allowed": security policy via policy.xml — limiting resources, disabling dangerous coders, and using the MAGICK_* environment variables. See you then!