AVIF to JPG Online — No Download, No Install

Most "online" converters are only online on the front-end: the moment you add a file, it travels to their servers where the real work happens. That is convenient for them, but it means your images live — at least temporarily — on someone else's hardware. This converter is genuinely local: your browser already knows how to decode AVIF, so the page simply uses that built-in capability, redraws each image, and hands you a JPG. There is no backend, no upload step, and no copy of your file anywhere but your own device.

The privacy difference is not theoretical. Designers sending client drafts, photographers working with unreleased shoots, and anyone handling ID scans or screenshots with personal information all have the same requirement: the file must not leave the machine. Running entirely client-side satisfies that by construction — the tool is incapable of uploading your images, because it never talks to a server in the first place.

It also removes an awkward category of worry that most people don't think about until it's too late. Upload-based converters have retention policies you can't inspect, third-party analytics scripts you can't audit, and infrastructure that can be breached, sold or subpoenaed. A page that never receives your file has none of those problems, regardless of who operates it or how honest their privacy policy is. The trust boundary is your own browser, which you already trust with far more sensitive things than photographs.

• Nothing to install — open this page in a modern browser and the converter is ready. No desktop app, no browser extension, no plugin.
• Works on any device — the same page converts AVIF to JPG on Windows, macOS, Linux, Android and iOS, because the heavy lifting is done by the browser itself.
• No sign-up or email — there is no account system at all, so there is nothing to leak and nothing to cancel.
• Free with no quota — convert one image or one hundred; the page imposes no daily limit and adds no watermark.

That matters more in some workplaces than others. If you use a company laptop, the software you may install is probably governed by an IT policy — and format converters from unknown publishers are exactly the kind of thing those policies exist to block. A browser page sidesteps the whole question: nothing is installed, nothing runs outside the tab, and the tool disappears completely the moment you close it. The same logic applies to borrowed machines, library computers, hotel business centres and any other situation where installing software is either impossible or unwise.

There is also no update treadmill. Desktop converters age: the version you downloaded in 2023 may not decode today's AVIF files correctly, and you are responsible for keeping it current. This page always uses whatever AVIF decoder your browser ships with, which the browser vendor updates on their normal release schedule — for free, and without asking you to do anything.

JPG dates back to the work of the Joint Photographic Experts Group, whose compression standard was finalised as ISO/IEC 10918-1 in 1992. In the decades since, JPEG has survived every attempt to replace it: JPEG 2000 arrived in 2000 with better compression but royalty-encumbered licensing, and almost nobody adopted it. WebP launched in 2010 and did eventually win real browser support, yet it still hasn't displaced JPG as the default export format of the photo industry. The reasons are boring and decisive: JPG has no licensing encumbrance in practice, thirty-plus years of decoder implementations on every platform ever made, and a critical mass of software that simply assumes any image input will be a JPG.

That installed base is what makes JPG the safe landing zone for any image that has to travel. A JPG created today opens in Windows XP-era software, in the photo frame your aunt owns, in every CMS ever written, and in the print RIP software at a commercial lab. No newer format can claim that, and none will for a long time. Converting AVIF to JPG is therefore less about abandoning the new format and more about picking the right currency for the transaction: AVIF where you control the pipeline, JPG where you don't.

AVIF is the still-image sibling of AV1, an open video codec published by the Alliance for Open Media (a consortium including Google, Amazon, Apple, Netflix, Microsoft, Intel and Mozilla, among others). The still-image format was specified in 2019, and it inherits AV1's intra-frame compression: what AVIF does to a single photo is essentially what AV1 does to one video frame. Because AV1 was designed to compete with next-generation licensed codecs like HEVC, its technology is modern — and that shows in the results.

What you actually get from AVIF, when the software around it cooperates:

• Much smaller files — for photographic content, AVIF routinely lands roughly 50% smaller than a comparable-quality JPG, sometimes more. At web scale that is a direct bandwidth saving.
• Higher bit depth — 10-bit and 12-bit colour support means smoother gradients with no banding in skies, sunsets and studio backdrops, where 8-bit JPG visibly struggles.
• HDR and wide colour — AVIF can carry HDR metadata and colour spaces well beyond sRGB, which matters for modern display pipelines.
• Alpha and animation — transparency and animated sequences are supported, making it a potential one-file answer to both PNG and GIF use cases.

On the adoption timeline: Chrome shipped AVIF by default in version 85 (September 2020), Firefox followed in version 93 (October 2021), and Safari added it in version 16 (September 2022). Opera and Edge, both built on Chromium, inherited support the same way. That covers the vast majority of current web browsing — but the web browser is a narrow slice of the software universe, and it is everywhere else that AVIF support remains thin.

Understanding what AVIF actually stores helps you predict what a JPG conversion will and won't preserve. AVIF uses the ISOBMFF container — the same family as MP4 — which means the image data is wrapped in a hierarchical box structure rather than a simple header. Inside that structure, the compressed payload is a single intra-coded AV1 frame. That is important because AV1 was designed to exploit perceptual redundancy in the same way its video competition (HEVC, VP9) does, but without the patent licensing overhead that made HEVC commercially awkward.

The colour data inside an AVIF frame is almost always stored as YCbCr rather than RGB. Y carries luminance — the brightness channel, where the human eye resolves most detail. Cb and Cr carry the two colour-difference signals. Because the eye is far less sensitive to colour variation than to brightness variation, AVIF (like JPG and most video) typically applies 4:2:0 chroma subsampling: the two colour channels are sampled at half the resolution of the luma channel in both dimensions. In plain terms, four luma pixels share one set of colour values. You rarely see this as a problem with photographs, but it does mean that rendering fine colour text over a chroma-subsampled background loses some colour precision — which is the same reason photographers shooting graphics or screen content sometimes bump AVIF to 4:4:4 (no subsampling) for archival use.

Bit depth matters for gradients. Standard JPG is 8 bits per channel (24-bit colour total), which gives 256 steps per primary. AVIF supports 10-bit and 12-bit colour, which is 1,024 and 4,096 steps respectively. Wide tonal ranges — skies at sunrise, studio backdrop gradients, shadows in raw photo edits — show visible banding at 8 bits; 10-bit smooths that out. When you convert a 10-bit AVIF to JPG, the converter tone-maps the image down to 8-bit: fine on most photographs, but you may see gradient posterisation on files that were specifically edited to exploit the extra headroom. AVIF also supports a separate alpha channel for transparency, encoded as a second AV1 frame alongside the main image. JPG has no alpha channel, which is why the conversion merges transparency onto a white background by default — more on that in the next section.

If you have tried to open an AVIF in Photoshop CC 2019, Windows Photo Viewer, or the default image viewer on an older Android phone, you already know the answer: a grey icon, a "format not supported" error, or nothing at all. The reason is not that those applications are poorly built — it is that AVIF arrived after they did, and image decoders are not automatically retrofitted into old software.

Opening an AVIF requires two distinct capabilities: understanding the ISOBMFF/HEIF container structure, and decompressing the AV1 bitstream inside it. Applications that pre-date 2019 have neither. Even some applications that added HEIF support for Apple HEIC photos — which use the same container family — did not extend that support to the AV1 codec payload, because HEIC uses HEVC compression and AV1 is an entirely different decoder. So an app might open your iPhone HEIC photos but still blank on an AVIF from a web download.

The practical upshot: any AVIF file you downloaded from a website, saved from a modern browser, or received from someone who shoots with a camera that exports AVIF will be invisible to a meaningful slice of the software your recipients use. Converting to JPG eliminates that variable completely.

The gap is easiest to see by trying things. Open an AVIF in a copy of Photoshop from a few years ago and it fails. Attach one to an email through a corporate gateway and it may be stripped or quarantined. Upload one to a marketplace listing, a property portal or a legacy CMS and you will usually hit an error message demanding JPG or PNG. Try to print one at a photo kiosk and the kiosk will shrug. None of this is a flaw in AVIF — it is simply that the long tail of software updates slowly, and some of it never updates at all.

So the practical strategy is straightforward: keep AVIF as your storage and delivery format where it is supported, and convert to JPG the moment a file needs to leave that comfortable circle — an email attachment, a client review, a marketplace listing, a forum post or a legacy publishing pipeline. Conversion is cheap; compatibility failures are not. A listing photo that gets rejected costs you a day; a JPG costs you nothing but a few hundred extra kilobytes.

Real work rarely involves a single image. Drop an entire folder of AVIF files and the queue processes them one by one, with live status and per-file error reporting. The quality slider applies to the whole batch — change it once and reconvert everything in a click. When the run finishes, download files individually or take the whole set as a single ZIP archive, with original and converted sizes shown next to every image so you can sanity-check the output before you download it.

A failed file never poisons the run. If one image in a folder of two hundred is corrupted or uses some corner of the format your browser can't decode, it is flagged in the list while everything else keeps converting — then you can retry the stragglers or exclude them, instead of starting the whole batch over. That continue-on-error behaviour is the difference between a tool that survives real folders and one that only survives demo folders.

Like every page on this site, the tool is financed by clearly labelled advertising rather than subscriptions or your data — the ads are the only third-party element here, and your image files never interact with them.

When a browser decodes an AVIF file, it produces a full-quality internal bitmap — every pixel the encoder originally preserved. Turning that bitmap into a JPG is a re-encoding step, and like any JPG encoding it offers a quality dial. At the default setting the result is visually indistinguishable from the source for typical photographs: colours stay accurate, gradients stay smooth, and text in screenshots stays legible. If you need smaller files for the web, lowering the slider trades a little fidelity for a lot of bytes; if you need a master copy, pushing it toward the maximum keeps nearly all of the detail the AVIF carried.

A little background on what that dial actually does helps when choosing. JPG compression works in frequency space: the image is cut into 8×8 pixel blocks, each block is transformed with a discrete cosine transform, and the higher-frequency data is quantised away more aggressively at lower quality settings. At high settings the discarded data is mostly invisible noise. At low settings it becomes visible as blockiness around sharp edges and mosquito noise near text — the classic JPEG artefacts. Somewhere between 80 and 95 on a typical encoder scale sits the sweet spot where files are dramatically smaller than quality 100 but look essentially identical; below roughly 60 the damage starts to show on real photographs.

One thing conversion cannot do is restore information that was already lost when the AVIF was created. AVIF is a lossy format, so if the original file was saved at an aggressive compression level, the converter faithfully reproduces what is there. For best results, always convert from the highest-quality AVIF you have — ideally the one your camera or export tool produced by default, rather than a copy that has already been squeezed once for social media.

AVIF supports a full alpha channel — a second compressed image layer that controls the opacity of each pixel independently. Logos with smooth edges, icons cut out over transparent backgrounds, and any image destined for a layered design workflow commonly use this. When you drop one of these files into the converter, the output JPG will look correct but will not be transparent — because JPG has no concept of transparency at all.

What actually happens during conversion is a process called alpha compositing, or more specifically premultiplied-alpha flattening. The converter reads the alpha channel and blends each pixel with a white background at full opacity: where the original was fully transparent, the JPG pixel becomes white; where it was fully opaque, the pixel is unchanged; and semi-transparent areas produce a smooth blend. The white background is the standard assumption because JPGs are most commonly viewed against white — documents, web pages, presentations. The result looks correct in those contexts and wrong on a dark or coloured background.

If you need to preserve transparency, convert to PNG instead of JPG. The AVIF-to-PNG page on this site does exactly that, using the same local conversion engine with no uploads. If JPG is specifically required — a platform that only accepts JPG — compositing onto white is your only option, and it is what this converter does automatically. The status indicator in the results list notes when an input file contained alpha, so you are never surprised by which files were flattened.

• Misconception 1 — "Converting AVIF to JPG improves image quality." It does not. JPG re-encoding always introduces some loss. At high quality settings the difference is invisible to the eye, but pixel-level comparisons will show it. The correct framing is compatibility, not quality improvement.
• Misconception 2 — "My JPG will be smaller than the AVIF." Usually the opposite is true. AVIF's AV1 compression is substantially more efficient than JPG's DCT algorithm — for a photographic image at comparable perceived quality, AVIF typically produces files 40–60% smaller. The JPG will almost always be larger. The exception is when the AVIF was saved at a very low bitrate (heavy compression artifacts) and you choose a very low JPG quality too — in that specific corner case the JPG can be similar in size — but you have also traded quality for both conversions.
• Misconception 3 — "AVIF to JPG is lossless if I set quality to 100." JPG quality 100 still applies quantisation — it is the mildest quantisation setting, not zero quantisation. True lossless preservation of every AVIF pixel is not possible via JPG. If your workflow demands lossless, convert to PNG instead; PNG is genuinely lossless and will reproduce the decoded AVIF pixel-for-pixel, at the cost of a larger file.
• Misconception 4 — "Old software will open the JPG the same as modern software." Almost certainly yes, but the metadata may not survive intact. EXIF orientation tags, ICC colour profiles, and GPS coordinates are embedded differently across encoder libraries. The converter writes standard EXIF into the JPG output, but complex colour profiles from HDR-mastered AVIF files may be simplified to sRGB. For critical colour-managed workflows, verify the output in your target application before distributing.

• Email attachments — many mail clients and corporate gateways still block or mangle AVIF; a JPG sails through every one of them.
• Client and stakeholder reviews — reviewers on older machines or locked-down corporate browsers frequently cannot open AVIF at all.
• E-commerce and marketplace uploads — most listing platforms formally accept only JPG (and sometimes PNG), no matter what format your camera or CDN exported.
• Print shops and photo labs — professional printing workflows are built around JPG, TIFF and PDF, and will often refuse AVIF outright.
• Documents and slide decks — office suites and presentation tools vary wildly in AVIF support; JPG embeds reliably everywhere.
• WordPress and older CMS installs — depending on version and configuration, many content management systems silently reject AVIF on upload, and fixing that means touching server config you may not control.

A concrete example of the pattern: a photographer delivers AVIF files from a modern pipeline to save client transfer time, the client opens them fine in Safari 16 — and then the client's accountant, using whatever came with a five-year-old Windows install, cannot open a single one. The fix takes thirty seconds here: convert the set to JPG once, send the JPGs, and keep the AVIFs for the people who can use them.

Because decoding and encoding both happen on your device, speed depends on your hardware rather than on someone else's server capacity — which also means there is no upload bottleneck and no queue you have to wait behind. A typical web-sized image converts in well under a second on any modern machine. Multi-megapixel camera files and very long batches take proportionally longer, since the browser decodes and re-encodes each frame at full resolution. Progress is shown per file, and a failure in one image never blocks the rest of the queue: the problematic file is flagged, the run continues, and you can retry the stragglers afterwards.

The rough scaling is easy to reason about: doubling the pixel count roughly doubles the work, since both the AVIF decode and the JPG encode scale with the number of pixels. A 12-megapixel image is about nine times the pixel count of a 1280×720 web image, so expect roughly nine times the time per file. On a recent laptop none of this registers; on a mid-range phone you will notice it at batch sizes above a few dozen large images.

If you are converting hundreds of very large images on a phone or tablet, expect the device to get warm and the process to slow down — that is the real cost of doing the work locally instead of renting someone else's data centre. It is also why browsers may throttle a background tab: keep this page in the foreground while a long batch runs, and it will finish faster.

Desktop applications (image editors, format utilities, command-line tools like ImageMagick or the avifenc/avifdec pair that ships with libavif) convert AVIF to JPG perfectly well, but they require a download, an install and varying degrees of technical confidence — and on managed work computers you may not be allowed to install anything at all. Upload-based web converters trade that inconvenience for a privacy problem: your images are copied to a server, processed there, held for some retention period the site may or may not disclose, and subject to whatever limits, watermarks or paywalls the operator chooses. Built-in OS tools are inconsistent: recent versions of Windows and macOS can open AVIF, but their "save as JPG" paths are buried, vary by version, and handle batches poorly.

A quick way to weigh them:

• Desktop software — most control and speed, but installs, updates, and OS permission issues; overkill for an occasional conversion.
• Upload-based web tools — no install, but your files leave the device, and free tiers typically cap file size, count per day, or both.
• OS built-ins — fine for one file if you know where the menu item hides, but no batch handling and the AVIF side varies by OS version.
• This page — no install, no upload, no quota, batch plus ZIP; the trade-off is that conversion speed follows your device rather than a data centre.

This page sits deliberately in the middle: browser-based like an online converter, but local like a desktop app. No install, no upload, no account, no quota.

You should not have to take a privacy claim on faith, so here is how to verify it yourself. Open your browser's developer tools, switch to the Network tab, and convert a few images. You will see no request carrying your file data — the only network activity on this page is the page itself and its clearly labelled advertising. The conversion code runs in JavaScript inside your tab, using the browser's native image decoders and the canvas API to redraw each image as a JPG. Your files are read from disk into memory, processed, and offered back to you as downloads; when you close the tab, nothing remains.

That verifiability is the real advantage over "trust us, we delete your uploads" promises from server-side converters. Here there is nothing to delete, because nothing was ever sent. You can go one step further if you like: the page works with your browser's offline state once it has loaded, because conversion needs no connection at all — flip your Wi-Fi off mid-session and the next conversion still succeeds. A server-based converter cannot pass that test.

Scroll to the converter at the top of this page, add your AVIF files by drag-and-drop or with the file picker, adjust the quality slider if you need something other than the default, and press convert. Results appear in a list with per-file status and size comparisons; download them one by one or grab the ZIP. There is no limit, no watermark and no sign-up — the only thing this page asks of you is a modern browser.

If you need a different output format, the same local engine powers AVIF to PNG conversion — use that when transparency must be preserved. For background on the formats and the full range of desktop conversion options, the AVIF to JPG guide covers command-line tools, OS built-ins and Photoshop workflows. If you have an AVIF you cannot even preview yet, the open AVIF file guide explains how to view one without installing a converter first. For the main tool with a step-by-step walkthrough, see the homepage.

Browser support for AVIF is now solid — Chrome, Firefox, and Safari all handle it — but the ecosystem beyond the browser remains stubbornly behind. Adobe Photoshop added AVIF support in version 23.2 (released early 2022), yet many organisations still run Photoshop CC 2020 or older under enterprise license agreements that restrict upgrades. Open a camera-roll AVIF in those versions and you get a blank grey canvas or an outright format-not-recognised error.

Microsoft Office is a bigger stumbling block. Word, PowerPoint, and Outlook do not render AVIF images as of the 2024 desktop builds — the image placeholder shows but the picture never loads. Dragging an AVIF into a PowerPoint slide deck produces a broken icon. Converting to JPG first takes ten seconds and eliminates the problem entirely.

Email clients are perhaps the worst offenders. Gmail on desktop renders AVIF inline, but Apple Mail on macOS Ventura and earlier does not. Outlook for Windows — used by most corporate recipients — ignores AVIF attachments when they are embedded as inline images in HTML email. If you send a newsletter or a proposal with inline photos, your recipients on Outlook will see empty boxes. JPG remains the only truly safe choice for embedded email imagery in 2026.

Beyond desktop software, many web platforms that accept image uploads — job-application portals, print-lab upload wizards, estate-agency listing tools, and government permit systems — run file-type validation against a static allowlist that was written years ago. AVIF is not on it. The upload silently fails or shows a vague "unsupported file type" error. Converting your AVIF to JPG before uploading sidesteps the validation entirely.

The three formats occupy different niches, and understanding those niches explains why you sometimes need to convert even a perfectly good AVIF file.

AVIF achieves the smallest file sizes at equivalent visual quality, particularly for photographic content with smooth gradients. Its compression algorithm — derived from the AV1 video codec — handles fine detail and shallow depth-of-field shots better than JPEG at the same byte count. WebP sits in the middle: broader software support than AVIF, smaller files than JPG, but still absent from many non-browser contexts. JPG is the universal donor. Every image viewer, every printer driver, every upload form written since 1995 understands it.

For print, the gap matters even more. Commercial print workflows — RIP software, digital press controllers, offset pre-press systems — almost universally work in CMYK colour space. AVIF and WebP are RGB-only formats; a print service bureau that accepts your AVIF will silently convert it through an uncontrolled RGB-to-CMYK transform, often with a colour profile mismatch that shifts skin tones and saturated reds. Supplying a JPG gives you the chance to do that colour-space conversion deliberately in Photoshop or a calibrated tool, preserving the intent of the image.

For transactional email — invoices, booking confirmations, shipping notices — JPG at quality 80 hits the sweet spot: small enough to load quickly on mobile, wide enough in compatibility to display in every mail client from Gmail to IBM Notes. AVIF's size advantage disappears the moment it fails to render in the recipient's client, and WebP still has gaps in Outlook on Windows. Until email clients standardise on a next-generation format, JPG is the pragmatic answer.

Modern Android phones have been saving AVIF by default since Android 12, and iPhone shooting in ProRes or High Efficiency mode produces HEIC files that some workflows export as AVIF. If you have been shooting for a year or two, your photo library may contain hundreds or thousands of AVIF files that need to become JPGs before you can share them with clients, import them into legacy editing software, or upload them to a stock photography platform.

Browser-based batch conversion — including the tool on this page — processes files entirely on your device using the browser's built-in codec. Nothing is uploaded to a server. You can drop a folder of fifty or a hundred AVIFs into the converter and download a ZIP of the resulting JPGs. For very large libraries (several hundred files), working in batches of 50–100 prevents the browser tab from exhausting available memory, particularly on machines with less than 8 GB of RAM.

One practical complication is naming. When you export a batch, the converter preserves the original filenames with the extension changed from .avif to .jpg. If your library contains files from multiple sessions that happen to share the same camera-generated names — IMG_0042.avif from two different shoots, for example — you will end up with a naming conflict in the output ZIP. Rename ambiguous files before converting, or sort them into per-session folders and convert each folder separately.

EXIF metadata — the embedded record of shutter speed, aperture, ISO, GPS coordinates, and capture time — is preserved during the conversion on this page. The EXIF block is copied verbatim from the AVIF container into the JPG output. However, if you use a command-line tool or a third-party converter that strips metadata by default, you will lose the capture timestamps that photo managers like Lightroom and Apple Photos rely on to sort your library chronologically. Always verify that the output JPGs carry the original DateTimeOriginal EXIF tag before deleting the source AVIFs.