Convert AVIF to JPG Online in Seconds

The whole process takes less than a minute, no matter how many images you have. You do not need to install software, create an account, or upload anything to anyone else's server. Everything happens inside this browser tab, which also means the page behaves the same on a Mac, a Windows laptop, a Linux desktop or an Android tablet — wherever your files happen to live. There is no watermarked output, no "premium speed" tier, and no email address requested at the end.

• Step 1 — Add your files. Drag and drop your .avif images onto the drop zone above, or click "Choose files" to select them from your device. You can add as many files as you like in one batch — 4 images or 400, the queue does not care.
• Step 2 — Pick your quality. The slider controls JPG compression from 50% to 100%. 85–95% is a sweet spot for photos; go lower when file size matters more than pixel-perfect fidelity. Every converted file shows its new size so you can verify the result immediately — a 1.8 MB AVIF hero image usually comes out at roughly 300–600 KB as a 90% JPG, which tells you instantly whether the setting is right.
• Step 3 — Download. Grab each JPG individually with its download link, or click "Download all as ZIP" to save the whole batch as a single archive. File names stay the same apart from the extension, so a folder of banner.avif, logo.avif and hero.avif comes back as banner.jpg, logo.jpg and hero.jpg.

A note on expectations before you start: conversion is a one-way street. Once an AVIF becomes a JPG, the file is larger and the AVIF-specific compression advantages are gone, so keep your originals where you can find them. The safest habit is to work from a copied folder — drop the copies here, download the JPGs, and the untouched AVIF originals stay on disk for the day you eventually need them. That matters more than it sounds: JPG has no way to get back the compression efficiency AVIF gave you, and re-converting a JPG back to AVIF later will not recover it either.

AVIF is not some experimental format cooked up in a garage — it is the still-image sibling of AV1, the video codec developed by the Alliance for Open Media. That alliance formed in 2015 and includes Google, Netflix, Amazon, Apple, Microsoft, Intel and Mozilla, all of them trying to build a royalty-free successor to the codecs that required licensing payments. The AV1 specification was finalized in 2018, and it took almost no time for someone to notice that a single frame of AV1 video is, structurally, a perfectly good still image.

The first stable version of the AVIF container specification was published in early 2019, and Netflix became its loudest champion almost immediately. In 2020 Netflix published engineering blog posts showing that AVIF images looked better than JPG at roughly half the file size, and they started shipping AVIF thumbnails in production. That endorsement is what pushed Chrome to ship support in September 2020 and what made CDNs and image services start offering AVIF as a delivery option. Every image service that followed — WordPress 6.5, Shopify's CDN, Squarespace, Cloudflare Image Resizing — turned AVIF on by default for modern visitors.

Which is how you ended up here. The format spread bottom-up through the web infrastructure: a CDN decided to serve AVIF to browsers that could take it, a designer saved web assets in AVIF, a client downloaded one, and suddenly someone without an up-to-date software stack is holding a file their tools cannot open. AVIF was designed for the delivery side of the web — saving bandwidth for companies streaming millions of images — not for the exchange side, where files pass between people running whatever software they happen to have. The compression numbers are real, but the compatibility assumption baked into every stage of its rollout was "modern browsers only," and the world is full of software that is not a modern browser.

This is the single most common reason people land on this page. You get an .avif file from a client — maybe from a web developer who exported web assets, or a designer working with a modern pipeline — and Photoshop refuses it with a cryptic error or just shows an empty canvas. Nothing is wrong with your machine. Adobe did not add AVIF support to Photoshop until version 23.2, which shipped in January 2022, and even then it arrived quietly. If you are running Photoshop 2021 (version 22) or anything older, the format simply does not exist as far as the app is concerned. Buying an upgrade to open one file is a bad deal; so is hunting for a plugin.

The two-minute fix: convert the AVIF to a JPG here, then open the JPG in your existing version of Photoshop like any other photo. At 95% quality the recompression is invisible for retouching and layout work. If your workflow needs layers or transparency preserved, convert to PNG instead — our AVIF to PNG converter handles that on the same terms, with no uploads. One practical tip for anyone working in print: keep the quality slider at 100% so downstream RIP software has maximum data to work with.

Photoshop is only the most famous name on a long list. Affinity Photo handled AVIF reasonably early, but Corel PaintShop Pro added it only in its 2023 release, GIMP requires version 2.10.30 or newer, and countless industry-specific tools — embroidery software, sign-making software, engraving controllers, school yearbook platforms — have never heard of the format at all. A surprising amount of professional imaging software updates on multi-year cycles, and AVIF is younger than those cycles. The pattern to remember: if the tool was released before 2022, assume it cannot read AVIF until proven otherwise, and just convert first.

Windows itself sits in an awkward middle ground here. Windows 10 gained AVIF support through the "AV1 Video Extension" from the Microsoft Store, but on many machines that extension was never installed, so File Explorer shows a blank or generic icon and the built-in Photos app refuses the file. Windows 11 handles AVIF out of the box for most installs, but enterprise images and locked-down machines frequently strip the codecs. If double-clicking the AVIF does nothing useful on your machine, converting to JPG sidesteps the entire codec situation — the OS has been able to show JPGs since the nineties.

You drag an AVIF into a PowerPoint slide and instead of your image you get a blank frame with a red X, or Word politely inserts a placeholder that says the picture cannot be displayed. Again — your file is fine. Microsoft only brought AVIF decoding to Microsoft 365 builds in 2023, and the perpetual licenses never got it at all: Office 2019 and Office 2021 do not support AVIF, full stop. That covers a staggering amount of the corporate world, because plenty of companies are still happily running Office 2019 on machines that will not be replaced for years.

The pattern is always the same: the deck looks perfect on the laptop of whoever made it (they were on Microsoft 365), then it falls apart the moment it reaches a client running Office 2019 or a conference-room PC that has not been updated since 2021. If the presentation has to survive contact with other people's computers, convert your AVIF images to JPG before inserting them. JPG has been supported by Office since the 1990s and will render identically on a Windows 7 box running PowerPoint 2010 — that is the kind of compatibility no modern format can offer yet.

One more Office wrinkle worth knowing about: even when a coworker on Microsoft 365 inserts an AVIF and it renders fine on their screen, the saved .pptx now depends on the recipient's Office version to decode it. There is no compatibility warning and no fallback image baked in — the deck simply breaks on older machines. Teams that pass decks back and forth have learned to standardize on JPG the hard way, usually after a client call where the slide in question turned into an empty white box live on screen.

The same trap exists in Google Workspace, just quieter. Slides and Docs usually convert an inserted AVIF to their own internal copy so it displays for everyone, but bulk imports — a Drive folder full of AVIF product images surfaced through a third-party add-on, for example — can behave unpredictably, and some add-ons reject the format outright. And macOS Quick Look, the spacebar preview, could not show AVIF files until macOS Ventura (2022). Every one of these little friction points has the same cure: JPG in, JPG out, and nobody in the chain gets a surprise.

It is worth pausing on why the target format is so unglamorous and so unbeatable. The JPEG standard was published in 1992 by the Joint Photographic Experts Group, and within a few years it was the default way photographs moved across the early web, into digital cameras, and onto every desktop operating system. A format that old has been ported to everything: the camera firmware on a 2007 flip phone, the screen firmware of a hotel-room TV, the receipt printer API at a pharmacy, the fax-to-email gateway at a hospital. When you convert to JPG, you are targeting the most widely implemented image decoder in history.

That longevity also means the entire toolchain around it is mature in ways modern formats cannot match. Every image library on every platform has optimized JPG decoding built in, every thumbnailer renders it, every CMS generates responsive sizes from it, and every print pipeline accepts it without a second look. There are no codec extensions to install, no licensing questions to ask, no version checks to run. Two files named photo.jpg behave identically whether they arrive in 1995 or 2026 — which is precisely the property AVIF cannot offer, no matter how good its compression is.

The honest trade-off is that JPG's compression is a generation behind. A photo that takes 400 KB as a good JPG might be 180 KB as AVIF at comparable visual quality, and for large image catalogs that difference adds up to real bandwidth money — which is exactly why the streaming giants pushed AVIF in the first place. But bandwidth is their problem, not yours. When the file needs to open on someone else's equipment, the extra 200 KB is a rounding error and the failed decode is not. Converting AVIF to JPG is how you hand a modern-compression file to a 1990s-compatibility world.

Chat apps are aggressive about recompressing images to save bandwidth, and most of them were built long before AVIF existed. Send an AVIF through WeChat and one of two things happens: the app refuses it or silently transcodes it, and the transcoded result that arrives on the other end is often noticeably blurrier than what you sent — bad news when the image is a product shot or a design proof. WhatsApp behaves similarly. The safest workflow anyone doing client work over chat has settled on is simple: convert AVIF to JPG first, send the JPG, and only mention the original format if someone asks.

There is a second benefit that matters even more for quality: chat apps tend to recompress JPG far more gently than an exotic format they have to process through a fallback path. A 90%-quality JPG sent as a regular image usually arrives crisp; the same picture forced through a transcode can come back with smeared text and visible banding in gradients. If you need pixel-exact delivery, convert here at 100%, then send the JPG as a file attachment rather than a photo — most apps leave file attachments untouched.

Messaging platforms are also where the "works on my phone" problem gets expensive. A supplier in one country views the chat on a mid-range Android from 2019, the client checks on an older iPad, and an intern forwards the image into a group where somebody is on a desktop app that has not been updated since installation. Each of those endpoints runs a different decoder, and AVIF support across them is patchy in ways no one documents. JPG is the only format that produces the same pixels at every hop. For anything commercial — quotes, proofs, listings, before-and-after photos — that predictability is worth far more than the bandwidth an AVIF would have saved.

Most people do not convert one image — they convert a folder that arrived as part of a job. Three situations come up again and again. E-commerce sellers get product photography delivered as AVIF because the studio's retouching pipeline exports web-ready files in whatever the newest format is, and then the marketplace rejects it: Amazon Seller Central wants JPEG, eBay image uploaders choke on AVIF, Etsy has historically rejected it, and Shopify theme image pickers vary by version. Converting the whole delivery folder to JPG at 90% takes under a minute here and clears the upload form on the first try.

Legacy CMS platforms are the second big bucket. WordPress before 6.5, Drupal before its AVIF module, countless proprietary systems from agencies, and just about every internal tool built between 2010 and 2020 validate uploads against a whitelist that reads something like jpg, jpeg, png, gif. A single .avif in the batch fails the whole form, or worse, uploads a file the site's thumbnailer cannot render, leaving broken product images live for customers. Converting to JPG before upload means the CMS generates every derivative size correctly, the CDN caches normally, and nothing lands on a developer's desk.

Print shops and photo labs round out the list. Their order systems frequently predate AVIF by a decade — a lab RIP might handle JPG, TIFF and PDF and nothing else — and a walk-in customer with phone photos synced through a cloud service that delivered AVIF gets told their files "aren't compatible." Front-desk staff who convert the batch to JPG at 100% quality in the browser, before it touches the print system, turn a fifteen-minute counter conversation into a normal order. The same move works for sign shops, engravers, sublimation printers and anyone whose production software updates on hardware cycles rather than web standards.

AVIF typically produces files around 50% smaller than JPG at equivalent visual quality — Netflix's own published comparisons put it at roughly half the size for the same perceptual score. After converting to JPG, your file will be bigger than the original AVIF, and that is not the converter being inefficient; it is the fundamental difference between the codecs. AV1's compression tools are simply newer and smarter than JPEG's block-based DCT from the early nineties. If a file's only job is to live on a fast modern website, AVIF is genuinely the better format and you should keep it there.

The reason to convert anyway is the destination, not the compression. A 600 KB JPG attached to an email opens everywhere; a 250 KB AVIF attached to the same email shows a broken-image icon on the recipient's Windows 10 machine without the codec pack. The extra kilobytes are insurance. And within the JPG side of the trade you still have real control: at 100% the converter keeps essentially all the detail for archival or print work, at 85–90% you get files that look identical on screen and upload fast, and at 60–70% you get thumbnails and preview images that weigh almost nothing. Watch the size column as you move the slider — the numbers tell you the trade-off for your exact files, not an average.

One counterintuitive case worth knowing: some AVIF files convert to JPGs that are barely smaller than the original, and occasionally larger. This happens with flat-color graphics, screenshots and text-heavy images — content AVIF compresses brilliantly and JPEG handles poorly, with its block artifacts visible around sharp edges. If your source is a screenshot with small text, check the output at 100% zoom before shipping it, and consider PNG for that file instead. Photographic content is where JPG is happiest, and converting photos is what this tool is for.

WordPress core only started accepting AVIF uploads in version 6.5, released in March 2024. Before that, attempting to upload an .avif to the media library got you the classic "Sorry, this file type is not permitted for security reasons" message — and beyond core, plenty of themes and page builders from before 2021 hardcode their own list of acceptable image extensions, so even a fully updated WordPress can choke on AVIF inside a slider, a gallery block or a logo field. Agency retainers full of 2019-era themes make this a weekly occurrence.

Rather than fighting the theme or installing a plugin just to whitelist one extension, the pragmatic move is to convert the AVIF to JPG and upload that. WordPress optimizes JPG natively, generates every responsive size on upload, and every caching plugin and CDN treats it as a first-class citizen. Once the site is running on WordPress 6.5+ with a modern theme you can revisit AVIF on the server side — until then, JPG is the format that never gets a support ticket filed against it.

There is a subtlety around image optimization plugins too. Smush, ShortPixel, Imagify and their competitors all handle JPG flawlessly because it is their home turf; their AVIF support varies by version and hosting environment, and on some server stacks the AVIF variant simply never gets served, so images silently fall back anyway. Editors and clients uploading from their own machines rarely know any of this — they just know the image "didn't work." A JPG coming in through the front door avoids the entire plugin-support matrix, and if the site owner later wants AVIF delivery, the right place to introduce it is the server-side optimization layer, not the upload dialog.

AVIF support in browsers arrived in pieces. Chrome shipped it in version 85 in September 2020, Firefox caught up in October 2021 (version 93), and Safari — notably — did not get it until Safari 16 in September 2022. Any browser older than that shows a broken-image icon where your picture should be. That matters when you send images to audiences you do not control: an embedded AVIF in a blog post silently fails for every visitor on an older machine, and neither you nor they get an error message explaining why.

Safari's late arrival deserves its own sentence of blame, because it defines the real-world floor. Anyone with an iPhone 8 or an older Mac stuck on macOS Monterey or earlier cannot render AVIF in the browser at all — and that population is not trivial. The same goes for Android: support depends on both the browser app and the device's hardware decoder situation, so budget phones from 2019 and 2020 are hit and miss. When a retailer embeds AVIF product images without a JPG fallback, they are quietly charging every older device a broken storefront. JPG is what you serve when you cannot check the recipient's version string first.

Email is worse. Classic desktop Outlook still does not render AVIF images in messages — the format that works elsewhere in the Microsoft ecosystem simply displays as a broken attachment or a blank rectangle in the reading pane. Since Outlook desktop remains the default mail client at a huge share of companies, any image you embed in a newsletter or a client email should be a JPG. It is the same logic as the Office 2019 story above: you are not choosing the best format, you are choosing the one that works on the oldest machine in the room. Converting takes seconds; a broken image in front of a client costs you a follow-up email and a little credibility.

The same logic applies to forum posts, customer support portals and internal wikis. Any surface where you cannot verify the reader's software stack is a place where AVIF gambles and JPG does not. A support agent attaching screenshots to a ticket has no idea whether the customer is on a two-year-old phone or a decade-old Windows machine — but a JPG looks the same on both, which is why every major helpdesk system still standardizes on it.

Photos carry EXIF metadata: camera model, exposure settings, timestamps, GPS coordinates when the phone had location on, and — the one that actually bites people — the orientation flag. Most phone cameras store the image rotated in the raw pixel data and record a small flag telling viewers to rotate it on display. Modern AVIF supports the same mechanism, and most software honors it. During conversion, the correct outcome is that the pixels come out already rotated the way you see them in the preview, so the JPG displays upright everywhere, including in the many older programs that ignore orientation flags entirely.

The reason this matters: some pipelines bake the rotation into the pixels and others keep the flag, and the two approaches disagree at the seams. If a converted photo appears sideways in one app and upright in another, it is an orientation-flag disagreement between those apps — not a corrupted conversion. The practical advice is to spot-check one portrait-mode photo from every batch in the destination software before sending all of it. If orientation ever looks wrong, open the JPG in any editor, rotate it explicitly, and save; the flag is then irrelevant because the pixels are genuinely upright.

Be aware that lossy conversion is also a fresh start for metadata in general. Some conversion paths strip most EXIF during re-encoding; others preserve it. Neither behavior is wrong, but the consequences differ: stripped GPS tags are a privacy win when sending house photos to a contractor, and lost color-profile information can matter for print work. If your image has an embedded color profile — many studio cameras use Adobe RGB rather than sRGB — verify the converted JPG's colors in the program you will actually use it in, and if anything looks desaturated, convert again from the original or let the destination tool handle the profile. Checking one file takes ten seconds and prevents an entire batch of surprises.

Traditional online converters upload your images to their servers, process them there, and send the results back. That means waiting for a transfer, trusting an unknown party with your photos, and often hitting file limits or paywalls for larger batches. This tool takes a different route: modern browsers ship with a native AVIF decoder, so your own computer already has everything needed to read the format. The conversion runs on your CPU, in your browser tab, with zero bytes of your images ever touching the network.

Besides privacy, local conversion is simply faster for everyday work. There is no upload wait for a 20-megabyte photo, no server queue during busy hours, and no rate-limiting after a handful of files. It also keeps working when your connection is slow or offline — the page only needs to load once. On a mid-range laptop, a typical 1200×800 photo converts in well under a second; the bottleneck is never the CPU, it is always the upload step on server-based sites.

There is a contractual angle too, if you work with other people's assets. Most client agreements, and effectively every NDA covering photography or unreleased products, assume files stay under your control. Running them through a third-party converter with an opaque retention policy is technically a disclosure — most services delete after an hour, "most" and "technically" being the operative words. Local conversion makes the compliance question disappear: the files never leave the machine, so there is nothing to promise, audit or trust. Under NDA, at the doctor's office, inside a company firewall — the browser route is the only one with no story to explain.

If a file cannot be decoded — for example because it is corrupted or you accidentally included a non-AVIF file — that item is marked as failed with a clear reason, and the rest of the queue keeps going. You always see exactly which files succeeded and which need attention, instead of discovering at download time that three of your fifty images silently produced garbage.

JPG is a lossy format, so some recompression is unavoidable when going from AVIF to JPG. The quality slider lets you decide how much: at 90% and above, differences from the original are practically invisible for photos and web graphics; at 60–75%, files get noticeably smaller at the cost of fine detail. As a rough guide, a batch of 20 product photos at 85% typically lands around 150–400 KB per image — small enough for email, good enough for print-in-a-pinch, and visually identical to the source on any normal screen.

If you want to be rigorous instead of trusting the slider alone, convert one representative file from the batch at two settings — say 85% and 100% — and compare file sizes. When the 100% file is under about twice the 85% file, take 100% and stop worrying; when it is three or four times larger, 85% is almost certainly indistinguishable for your use. This two-file test takes fifteen seconds and replaces a lot of folk wisdom about "the right quality setting," because the answer genuinely depends on each image's detail level, not on a universal number.

Because JPG does not support transparency, any transparent pixels in the AVIF source are filled with white during conversion — the right choice for photos and the standard behavior of every converter. If you need that transparency kept (a logo, an icon, a cut-out product shot destined for a page with a colored background), do not force it through JPG. Convert to PNG instead: our AVIF to PNG tool preserves the alpha channel exactly, and files only a fraction larger. Not sure what your AVIF actually contains? You can preview it in place first with the AVIF file viewer without converting anything, or compare both destinations side by side from the AVIF to JPG online overview page.

A few habits make large runs painless. Sort your folder before you start: the queue preserves the order files were added, so renaming with numeric prefixes (01-hero.avif, 02-gallery.avif) gives you a predictable ZIP. Set quality once before the queue starts — although you can change it mid-run, one decision up front means every file gets the same treatment. And keep an eye on the size column: if a 4 MB AVIF refuses to shrink below 3 MB as a JPG, it is almost certainly a highly detailed photograph where AVIF's compression genuinely outperforms JPG, and you may want to reconsider whether converting it serves you at all.

For mixed jobs — say a client delivers 60 AVIF photos and 6 logos with transparency — run two passes. Convert the photos to JPG at 90%, then send the logos through the PNG tool. Total time for both passes on a decent machine: about a minute, versus 10–15 minutes of upload waiting on a typical server-based converter site.

Very large batches benefit from one more habit: convert in chunks of fifty to a hundred files and download each ZIP before starting the next chunk. The queue itself can handle hundreds without complaining, but a single enormous ZIP is awkward to download, verify and share — a 250-file job splits cleanly into three archives that each fit in an email or a chat upload. While a chunk converts, you can keep working in other tabs; the conversion runs at normal priority and will not make your machine unusable. If the tab does get closed by accident, nothing is lost except the queue itself — the originals are untouched on disk, which is exactly why browser-side conversion fails so safely.

Honestly, it usually is — not because JPG is technically impressive, but because it is the only image format that opens correctly everywhere: Photoshop 2021, PowerPoint 2019, desktop Outlook, a 2018 Android phone, a five-year-old WordPress theme, your client's ancient print vendor portal. AVIF wins on compression, WebP wins on flexibility, but when the question is "will this image display for the person I am sending it to, on whatever they happen to be using?", JPG is the safe answer. That is precisely why this converter exists: AVIF is great at getting images to you, and JPG is great at getting images from you to everyone else.

The gap is closing, to be fair. AVIF is a decade old at most and already runs on every current browser, most phones, and the latest creative software; give it another few years of enterprise software cycles and the converter stories on this page will start to sound historical. But "a few years" is doing heavy lifting in that sentence — the Office 2019 perpetual license will still be installed in 2030, the Windows 10 machine without the AV1 codec extension will still render broken images, and the print shop RIP will still want a JPEG. Until every link in your particular chain has been replaced, the thirty-year-old format remains the one you hand to strangers, and AVIF remains the one you accept from strangers and convert on the way through.