Batch Convert AVIF Files to JPG

Drop your files onto the tool above and each one enters an individual queue slot. You can see the filename, file size, and a live status badge — Waiting, Converting, Done, or a short failure reason — for every item at once. Conversion runs one file at a time in the order they arrived: the browser decodes the AVIF using its native AV1 decoder, draws the result onto an offscreen canvas, and re-encodes it as a JPEG at whatever quality you have set on the slider. Each finished file gets its own download button immediately, so you can grab the ones you need before the rest are done.

When the whole batch is finished, a single "Download all as ZIP" button packages every output into one archive. The ZIP is assembled in the browser using the same local approach as the conversion itself — no server, no upload, no size quota. If you change the quality slider after a run, a "Reconvert all" button restarts the entire queue at the new setting without you having to re-drop the files. This is the fastest path when you are calibrating output quality against file size across a set of images you already dropped in.

You can also use our single-file AVIF to JPG converter when you only have one image to convert and want to preview the result before downloading. The batch tool and the single-file tool share the same local conversion engine — the difference is purely in how many items you feed it at once.

A batch rarely arrives with every file in perfect shape. Screenshot utilities sometimes save broken AVIF containers, downloaded files get truncated mid-transfer, and occasionally a file with a .avif extension is actually a different format with the wrong name. Any of these will fail to decode.

When that happens, the queue slot for that file turns red and shows a short reason — "Not a valid AVIF", "Truncated container", "Decode error" — and conversion continues immediately with the next file. The bad item is never retried automatically, so it cannot stall the queue. Every other file in the batch completes normally. At the end you can see exactly which files failed and why, download all the successful outputs, and deal with the failures separately.

This matters most on large batches from automated sources — a folder of downloaded files, a screen-capture archive, an asset export from a CMS — where you have not inspected each file individually. The tool tells you exactly what it could not handle, rather than silently skipping files or stopping the whole run at the first error.

Browser-local conversion is bounded by device memory, not by any artificial limit in the tool. Understanding the arithmetic helps you pick the right batch size.

When an AVIF is decoded, the result is a raw RGBA raster: four bytes for every pixel, regardless of how small the compressed file was. A 5-megapixel image occupies 5,000,000 × 4 = 20 MB in memory. A 20-megapixel image occupies 80 MB. The JPEG encoder then needs its own working buffer on top of that, so peak memory for a single 20-megapixel conversion can land well above 100 MB. On a desktop with several gigabytes of RAM available to the browser tab, this is never a problem. On a phone, where browsers share a smaller pool, it is the real ceiling.

• 20–50 small-to-medium images (typical web screenshots, product shots under 3 MP) — these run in a single pass on any modern device, phone included.
• Large images above 10 MP — process in batches of 10–20 and give the browser a few seconds between passes to release memory. Closing unrelated tabs helps on phones.
• 48 MP camera images — a 48-megapixel AVIF decodes to a 192 MB raster. Convert these one or two at a time, or on a desktop rather than a phone.

If a conversion fails with a memory-related error, the queue slot will show a reason and the next file will start automatically. The fix is to reduce the number of large files in a single pass, not to reduce image quality — quality does not affect how much memory the decode step needs, only how large the output file is.

Upload-based converters work the same way: your files go up over your internet connection, a server converts them, and the results come back down. That model made sense when browsers could not decode AVIF natively. It no longer does — every major browser has shipped an AV1 decoder, so the conversion can happen entirely on your own machine.

• No upload bandwidth consumed. Uploading is typically slower than downloading on home and office connections. A batch of 30 high-resolution AVIFs can take minutes to upload; local conversion finishes in seconds. The speed difference is most noticeable on slower connections — which are exactly the situations where an upload-based service is most painful.
• No file size or count quotas. Free tiers on server-side converters typically cap individual file size, daily file count, or both. There is no such cap here. The only limit is your device memory, which scales with file count and resolution rather than an arbitrary tier.
• NDA and sensitive materials stay on your machine. Unreleased product photography, client assets covered by confidentiality agreements, and proprietary design files should not travel through a third-party server with an opaque retention policy. Local conversion means the files never leave the tab. You can load this page, disconnect from the network, and convert normally — the network is not involved at any point after the page loads.
• No account, no email, no API key. Drop the files, get the JPGs, close the tab. The entire session state is gone when the tab closes.

The honest trade-off is that very large batches of high-resolution files can saturate device memory on phones, whereas a server has as much RAM as the provider provisioned. For desktop use — which covers most professional workflows — local conversion is straightforwardly better in every dimension that matters.

The quality slider applies to every file in the batch uniformly. Unlike PNG, JPEG is lossy — lower quality means smaller files but softer detail and more compression artifacts, particularly around sharp edges, fine text, and gradients. The right setting depends on what the output is for.

• Quality 75–80: Web thumbnails, preview images, and assets where file size matters more than pixel-perfect detail. Fine for faces and general photography; avoid for images with sharp text or technical diagrams.
• Quality 85–90: General-purpose sharing — sending images to colleagues, uploading to a CMS, attaching to email. The file is noticeably smaller than the 95+ range while looking clean at normal viewing sizes.
• Quality 92–95: Images you plan to re-edit, or where the recipient might zoom in and compare closely. Compression artifacts are minimal at this range.

One important caution for batch work: every JPEG re-encode adds another generation of lossy compression. If you convert an AVIF to JPG at quality 85, edit the JPG, and then save it as a JPG again, you are compressing an already-compressed image. The artifacts stack. If there is any chance the output will be edited again, convert at 95 or higher and keep the JPG only as a delivery copy, not as a working file. For images you plan to edit seriously, consider converting to PNG instead, which is lossless and immune to this problem.

Knowing when to use batch conversion — and how to set it up — is faster than figuring it out case by case. These are the most common patterns.

An entire download folder of AVIF assets. Modern browsers and screenshot tools increasingly save in AVIF by default. If you have accumulated a folder of .avif files that a colleague, client, or CMS cannot open, select all of them, drop them in at once, wait for the queue to finish, and download the ZIP. The JPGs will have the same filenames with a .jpg extension and can be shared immediately. Converting AVIF to JPG one at a time is fine for one or two files; for a folder of thirty it is not.

Camera or phone exports. Some camera manufacturers and editing apps now export AVIF when the user picks "high efficiency" mode. If the recipient uses software that predates AVIF support, a batch conversion to JPG at quality 90 gives them universally compatible files at a fraction of the PNG equivalent size.

Web scraping and research archives. Images saved from modern websites often arrive as AVIF. Dropping the batch into the converter gives you a folder of JPGs that can be imported into any slide deck, document, or image management tool without format errors.

Pre-upload preparation. Many stock photo platforms, social networks, and CMS upload forms accept JPG but not AVIF. Run your batch through the converter at the platform's recommended quality setting before uploading, and you avoid the silent re-compression those platforms apply on the server side when they encounter a format they prefer not to store.

If the conversion has to run inside a build pipeline, a CI job, or a folder-watch script rather than interactively, two tools handle AVIF batch conversion reliably.

FFmpeg with a shell loop converts every AVIF in the current directory. The -q:v 2 flag sets quality on JPEG's internal scale, where 2 is near the top (roughly equivalent to quality 95 in most other tools):

for f in *.avif; do ffmpeg -i "$f" -q:v 2 "${f%.avif}.jpg"; done

ImageMagick's mogrify command processes an entire glob in one invocation and writes the output files next to the originals:

magick mogrify -format jpg *.avif

Both commands run on macOS, Linux, and Windows (WSL for the shell loop version). ImageMagick requires a build with libheif and AV1 support compiled in — run magick -list format | grep -i avif to confirm it is present before relying on it in a script. FFmpeg's AV1 support comes through libdav1d, which is included in standard distribution packages.

For one-off interactive batches — a folder of downloaded files, a set of exports you need converted right now — the browser tool above is faster: no command line, no environment to configure, and the files never leave your machine regardless of which approach you use. Check how to open AVIF files if you need more context on the format before converting.

A product photographer shoots 80 frames at a trade show. The camera app exports AVIF by default and the files land in a shared folder. The photographer drops all 80 into the batch tool, sets quality to 85, and clicks Download all as ZIP. The whole run takes under two minutes on a mid-range laptop — no account, no waiting for upload progress bars, no email with a download link that expires in 24 hours. The ZIP goes straight to the art director via Slack.

A web developer migrates a legacy image library. The old CMS stored everything as JPEG. The new CMS exported everything as AVIF during migration. Now a plugin expects JPEG and refuses the AVIF files. The developer sorts the folder by file type, selects all 340 .avif files, drops them in one batch, and has a ZIP of JPEGs in a few minutes. No command-line tool to install, no Docker image to pull, no ImageMagick flags to look up.

A designer prepares screenshots for a client deck. macOS Safari saves screenshots as AVIF on some system configurations. PowerPoint and Keynote both accept JPEG without any warnings. The designer selects the 12 screenshots, drops them in, sets quality to 92 to keep the text crisp, and downloads them individually — one click per file, done as each one finishes. The deck imports cleanly on Windows without any format negotiation.

The most common mistake is setting quality too high out of caution. Quality 95 on a batch of 50 product photos produces files that are three to four times larger than quality 85 with no perceptible visual difference at any normal display size. The right mental model: quality 85 is not "low quality" — it is the professional web delivery standard that most stock photo libraries use internally. Reserve quality 92 and above for source material you plan to edit again, not for delivery copies.

A second mistake is converting files that were already JPEGs renamed to .avif. This can happen when a tool misidentifies a format and mislabels the output. If a file shows "Not a valid AVIF" in the queue, check the original — open it in a hex editor or use the single-file converter to see what the browser makes of it. A genuine AVIF starts with a specific ISO Base Media File Format box sequence; a mislabeled JPEG starts with the bytes FF D8 FF instead.

A third mistake is re-compressing files you have already converted. If you convert at quality 85, get the ZIPs, realize you wanted 88 instead, and then run the JPEGs through the converter again rather than reconverting from the original AVIFs, you are compressing compressed data. Each generation of JPEG encoding introduces new DCT artifacts on top of the previous ones, and the damage is not reversible. Always go back to the original AVIF if you want a different quality level — the "Reconvert all" button exists precisely for this reason.

Each converted file keeps the original filename with its extension replaced by .jpg. A file called product-hero-2024.avif becomes product-hero-2024.jpg. The ZIP archive mirrors this: every file sits at the root of the archive with its new name, no subdirectories. If your source files had a folder structure, that structure is not preserved — all outputs land flat in the ZIP. For most one-off batches this is the right default, because you are usually delivering a flat folder of assets rather than a nested directory tree.

When you need to preserve structure, the practical approach is to batch-convert each subfolder separately and keep track of which ZIP came from which folder. This adds a few extra steps but keeps the output organized without requiring you to rename files after extraction. Alternatively, if you are running a large structured archive, the command-line approach described in the section above gives you full control over output paths and preserves whatever tree structure you specify in your script.

Filenames with non-ASCII characters — accents, Chinese characters, emoji — are preserved correctly in both the individual downloads and the ZIP. The archive is assembled using UTF-8 file name encoding, which modern operating systems on Windows, macOS, and Linux all handle without issues. If you are sending the ZIP to someone on an older Windows system using legacy ZIP software, some tools from that era interpret file names as system codepage rather than UTF-8 and may display garbled names — a known limitation of old ZIP implementations, not a conversion issue.

AVIF is built on the AV1 codec developed by the Alliance for Open Media. It achieves its small file sizes through aggressive intra-frame prediction — the encoder looks at surrounding areas of the image to predict each block, then stores only the difference between prediction and reality. That approach is very effective for photographic content and allows AVIF files to carry substantial visual information in a small container.

When you convert to JPEG, you are switching to a different lossy codec — JPEG uses discrete cosine transforms on 8×8 blocks, a much older approach. At matched visual quality, the JPEG output will generally be larger than the AVIF source. A 200 KB AVIF photo at quality 95 might become a 700 KB–1 MB JPG, depending on subject detail. This is expected behavior, not a flaw in the conversion. You are trading AVIF's compression efficiency for JPEG's near-universal compatibility.

For a detailed technical comparison of these two formats and when each makes sense, the AVIF vs JPG comparison covers the trade-offs in depth. The short version for batch work: convert at the quality your destination requires, not the highest setting available, and you will keep output sizes reasonable without any visible quality loss at normal viewing distances.