Change AVIF files to JPG quickly when you need broad compatibility.
AVIF support in 2026 looks like this: Chrome, Firefox, Safari (since Ventura), and Edge all display AVIF images in web pages. That's the good news. The problems start everywhere else.
Email clients are the biggest pain point. Microsoft Outlook on Windows renders images using Word's HTML engine, which has no AVIF decoder. Apple Mail handles it fine on macOS Ventura+, but many corporate environments run older versions. Gmail's web client supports AVIF, but the mobile app on older Android builds does not reliably display inline AVIF images.
CMS and social platforms lag behind. WordPress added AVIF upload support in version 6.4, but many shared hosting environments disable it because the libavif dependency isn't compiled into their PHP builds. Instagram, Facebook, and LinkedIn accept AVIF uploads but internally convert them to JPG anyway — so uploading AVIF to these platforms gains you nothing while adding a conversion step on their end that you can't control.
Desktop software splits sharply. Adobe Photoshop has read AVIF since version 23.1 (2022), but Illustrator still can't place AVIF files natively as of version 29. GIMP supports AVIF. Figma supports AVIF. Canva does not. Microsoft Paint does not. The Windows Photos app requires the AV1 codec extension.
For anyone collaborating with clients, vendors, or team members whose software stacks they don't control, converting to JPG before sharing remains the only reliable path.
Understanding the conversion helps you make better quality decisions. AVIF and JPG use fundamentally different compression approaches, and the trade-offs during conversion are worth knowing.
AVIF's architecture: AVIF stores images using the AV1 intra-frame codec inside a HEIF container. It supports 8-bit, 10-bit, and 12-bit color depth, chroma subsampling configurations from 4:4:4 to 4:0:0, and both lossy and lossless modes. Its transform coding uses larger block sizes (up to 128×128) and more sophisticated prediction modes than JPEG, which is why AVIF handles flat areas, gradients, and sharp edges more efficiently.
JPG's architecture: JPEG compression divides the image into 8×8 pixel blocks, applies a discrete cosine transform (DCT), quantizes the coefficients, and entropy-codes the result. It's limited to 8-bit color, 4:4:4 or 4:2:0 chroma subsampling, and has no native support for transparency or animation.
During conversion, several things happen simultaneously:
The AV1 bitstream is decoded back to a full pixel buffer. If the source was 10-bit or 12-bit, values are downsampled to 8-bit per channel — this is where subtle gradient information can be lost. The chroma planes are re-sampled if the source used 4:4:4 subsampling and the output uses 4:2:0 (the JPG default). Any alpha channel is either composited onto a background color or discarded. The resulting pixel data is then encoded through JPEG's DCT pipeline.
The quality slider in the converter controls the JPEG quantization table — lower values discard more high-frequency detail, producing smaller files with more visible blocking artifacts at extreme settings.
Converting AVIF to JPG isn't always the best move. Here's an honest assessment of when it makes sense and when you should consider alternatives.
Convert to JPG when:
You need to email an image to someone whose email client won't render AVIF. You're uploading to a platform that will re-encode anyway (social media, most marketplaces). You need the file in a format that every piece of software on earth can read. You're working with a print vendor who requires JPEG submission. You're embedding images in a PowerPoint or Google Slides presentation.
Consider converting to PNG instead when:
The image contains transparency (AVIF supports alpha; JPG does not). You need lossless quality preservation — though the file will be significantly larger. The image is a screenshot, diagram, or UI element where sharp pixel-level accuracy matters and JPEG's blocking artifacts are noticeable.
Keep the AVIF when:
You're serving images on a modern web property where you control the delivery pipeline. File size is critical and your audience's browsers support AVIF (check your analytics for browser breakdown). You need HDR or wide-gamut color representation — JPG's 8-bit limitation cannot reproduce the full dynamic range of an AVIF HDR image.
If you're converting a single image, the process takes seconds and file size differences are negligible. Batch conversion introduces decisions worth thinking about.
A typical AVIF file from a 48MP smartphone camera at default quality is roughly 1.5-3MB. The same image as a JPG at quality 90% will be 4-8MB. At quality 80%, you're looking at 2-4MB — closer to the original AVIF size but with visible compression differences in fine detail areas like foliage or fabric texture.
For web use after conversion, running your JPGs through a JPG compressor can recover much of the file size advantage you lost by converting from AVIF. A two-step workflow — AVIF to JPG at quality 95%, then aggressive JPG optimization — often produces files that are within 20-30% of the original AVIF size while maintaining broad compatibility.
Batch naming conventions matter. When converting dozens of files, the tool preserves original filenames with a .jpg extension. If your AVIF files already have descriptive names (product-4501-hero.avif), the converted JPGs inherit them cleanly. If you're working with cryptic filenames from a camera or export pipeline, rename before conversion to avoid confusion later.
This is the part most conversion tools gloss over, and it matters more than people realize.
Color profiles: Many AVIF files, especially those from modern smartphones, embed an ICC color profile — often Display P3 for Apple devices or sRGB for Android. During conversion, the converter preserves the embedded ICC profile in the output JPG. However, not all applications honor embedded profiles correctly. If you notice your converted JPGs look slightly more saturated or washed out compared to the originals, the viewing application is likely ignoring the color profile and assuming sRGB.
EXIF metadata: Camera metadata (shooting parameters, GPS coordinates, device information) transfers to the JPG output. This is useful for photography workflows and asset management, but be aware of it if you're sharing images publicly — GPS coordinates in EXIF data reveal location information.
Orientation tags: AVIF files from mobile devices often store the image in landscape orientation with an EXIF rotation tag. The converter respects this — your JPG will display with the correct orientation. Some very old applications ignore orientation tags, which can result in rotated images. If this happens, the fix is a manual rotation in any image editor, not a conversion problem.
"My converted JPG looks different from the AVIF"
Usually a color space issue. Open both files in an ICC-aware application (Photoshop, Preview on macOS, Firefox with color management enabled) and compare. If they match there but differ in a basic viewer, the viewer is the problem, not the conversion.
"The file size increased dramatically"
Expected behavior. AVIF's compression is genuinely more efficient than JPG's, especially for images with large flat areas, smooth gradients, or fine repetitive textures. A 500KB AVIF becoming a 1.5MB JPG at equivalent visual quality is normal. Use quality 80-85% to bring the size closer to the original.
"Transparency disappeared"
JPG does not support transparency. If your AVIF had an alpha channel, it was composited onto a white background during conversion. If you need to preserve transparency, convert to PNG instead.
"The file won't convert"
Rarely, an AVIF file may use encoding features (like 12-bit depth with specific matrix coefficients) that cause compatibility issues. Try opening the file in a desktop application like GIMP and re-exporting as AVIF with standard settings before converting. Alternatively, the file may be corrupted — verify by trying to open it in Chrome, which has the most permissive AVIF decoder.
Conversion doesn't have to be a one-way street. If you convert AVIF to JPG for a specific use case — sharing with a client, submitting to a platform, embedding in a document — you can always convert back to AVIF later for storage or web delivery.
Keep in mind that this round-trip (AVIF → JPG → AVIF) does not restore the original AVIF quality. Each lossy encoding pass discards information. The second-generation AVIF will be slightly worse than the original, and the file size may not match the original either, since you're now encoding JPG artifacts into AVIF rather than encoding the original pixel data.
The practical takeaway: keep your original AVIF files archived if you think you'll need them. Storage is cheap. Regretting a destructive conversion is expensive in time and quality.