AVIF to JPG Converter

Nothing to download: your browser is the decoder

This page fetches no decoder. In the methodology page's words, current Chrome and Edge, Firefox 93+, and Safari 16.4+ decode AVIF natively, so AVIF to JPG uses the browser's own codec with a runtime feature probe and a plain-language notice when a browser cannot. The engine keeps a list of formats decoded only by the browser's own codecs, with no fallback vendored on purpose; asked whether AVIF is on that list, it answers yes. The probe is a decode rather than a version check: when the page loads it asks the browser to decode a tiny known-good AVIF, and only when that fails is the notice beneath the controls in the tool card revealed. A file that later refuses to decode on a browser that passed the probe is reported on its own row as a file that would not decode, not as a missing codec.

Decoding runs through createImageBitmap with imageOrientation: 'from-image', so any orientation the file declares is applied as the pixels are produced. From there the lane is short: the bitmap is drawn to a canvas, composited over your chosen background colour first because the target cannot hold transparency, and written out by the browser's JPEG encoder at the quality the plan carries. No vendored module runs on this page in either direction. The self-hosted codecs the site keeps under /vendor/ belong to the HEIC pages and to the pages that produce AVIF or run MozJPEG, never to this one.

What the detector sees before anything is planned

The first thing the tool does with a file is read its leading bytes. AVIF has no fixed signature the way PNG or JPEG do; it is an ISO-BMFF container, and what leads the file is an ftyp box: four bytes of size, the ASCII ftyp, a four-character major brand, four bytes of minor version, then compatible brands four characters each to the end of the box. The detector parses that structure and never substring-searches the file; the declared size is clamped to the bytes actually present, so a truncated or hostile header stops the read instead of pushing it past the buffer. A file is AVIF when the brand list carries avif or avis, unless an explicitly HEVC-coded brand is also declared, in which case HEIC wins. Three boxes constructed at build time show the verdicts this lane depends on. A major brand of avif with compatibles mif1 and miaf reads as avif mif1 miaf, is detected as AVIF, and declares an image sequence: no. A major brand of avis with compatibles avif, msf1 and mif1 reads as avis avif msf1 mif1, is detected as AVIF, image sequence: yes — that brand is what drives the first-frame caveat below. A box led by heic is detected as HEIC; dropped on this page it is refused as HEIC and pointed to the HEIC converter, because a lane built for one source format does not quietly accept another. The guide walks the parser's rejections one by one; this page needs only the verdicts that change its plan.

Names are compared, not trusted. After detection the filename's extension is checked against the verdict, and a disagreement is shown on the row before anything is converted. The case that matters on this lane is a file whose bytes are AVIF but whose name already ends in the target's extension. An invented scan.jpg wrapped around the still box is detected as AVIF while the name claims JPEG, mismatch yes. It converts from the actual AVIF content, and because the output would otherwise carry exactly the input's name, the download becomes scan-converted.jpg — the one situation in which a suffix appears. Spelled scan.jpeg instead, the same bytes become scan.jpg, since the canonical extension differs and nothing is shadowed. Named IMG_2210.heic, the extension claims HEIC, the mismatch is yes, and the download is IMG_2210.jpg; correctly named scan.avif, the mismatch is no.

What the plan decides for AVIF to JPEG

Before any pixel moves, a pure planning module takes the detected source and the target and returns a plan; the client then does only what the plan says. For this pair, computed at build time by the same function the tool calls on your file, with the controls at their defaults:

• Encoded as image/jpeg, the MIME type handed to the browser's encoder; the download carries the .jpg extension.
• Flatten over a background: yes, onto #ffffff. The capability table says JPEG cannot hold alpha, and a HEIF image can carry an alpha plane, so the planner sets this flag for every AVIF source — it decides from the formats, not from the pixels. The colour picker above feeds this field; choose it before converting, because the composite cannot be undone afterwards.
• Quality: 0.92, JPEG's default in the capability table; the slider's readout of 92 is that value on the 0–100 readout scale. JPEG is lossy, so the plan always carries a quality.
• First frame only: yes. The avis brand makes AVIF an animatable container, so the plan sets this flag for every AVIF source; the row's note that only the first frame was converted appears when the file actually declares avis — yes for the sequence box above, no for the still one.

Move the controls and the plan follows. With the slider at 80 and the picker on black, the plan carries a quality of 0.8 and a background of #000000. The slider's two ends map to 0.05 and 0.95, both accepted, and the planner's own ceiling of 1 is accepted too. The planner refuses rather than guesses: asked for a quality of 0.04 it returns "Quality must be between 0.05 and 1.", and asked to flatten onto a colour named white it returns "Enter the background as a hex color like #ffffff." — a three-digit form such as #fff is accepted and recorded as #fff. For contrast, the same source planned to PNG sets flatten to no and quality to none: that single difference is why AVIF to PNG keeps transparency and asks for nothing, and why this page asks for a colour.

The encoder: the browser's JPEG writer, and what a quality number is

The JPEG on this lane is written by the browser's own JPEG encoder through the canvas — one of the three browser encoders the methodology page lists beside the two self-hosted ones. The plan hands it image/jpeg and the quality on the engine's zero-to-one scale, and the encoder does the rest. Nothing about that step is vendored, which separates this page from Compress JPEG, where the same target format is written by the self-hosted MozJPEG module — libjpeg-turbo under the IJG, Modified BSD and zlib licences, with a binding derived from the Squoosh/jSquash wrapper under Apache-2.0 — and from JPG to AVIF and PNG to AVIF, which load libavif + aom. The licence texts the site ships under /vendor/mozjpeg/ and /vendor/avif/ describe modules this page never fetches.

What the quality number is, mechanically: a parameter the encoder takes, bounded by the planner to 0.05–1 and by the slider to 0.05–0.95. It is not a percentage of the original's quality and it is not a prediction of size. This site publishes no recommended setting, because the right value depends on the image and on what the file is for, and neither is something the engine can read. What the engine can tell you is what each setting produced: the measured byte count on the row and the dimensions it verified. Two consequences follow from a lossy target. First, the decoded pixels are encoded again, lossily, by the JPEG pass according to its parameter; whatever the source's own encoding already dropped, and whatever JPEG drops, is not recovered by converting back to AVIF later. Second, every pixel is opaque on the way out: there is no alpha to hold, so the composite over the background colour is final.

What re-encoding strips

Canvas re-encoding strips all embedded metadata: EXIF (including GPS location, camera model, and timestamps), colour-profile tags, and text chunks. The methodology page presents this as both a feature and a caveat, and it is both — a converted photo published from here cannot reveal where it was taken, and equally, copyright fields and ICC profiles are gone, so originals should be kept. Orientation is the exception in effect though not in mechanism: it is applied during decoding, before the metadata is discarded, so the picture stays upright even though the orientation tag does not survive. Nothing on this page reads, edits or re-inserts metadata; the output carries what the browser's JPEG encoder writes, and no more.

Filenames: stem kept, extension swapped

The output name keeps your stem and swaps in the target's canonical extension, jpg. Computed at build time on invented names: IMG_0042.avif becomes IMG_0042.jpg; Sunset.AVIF becomes Sunset.jpg, the stem's case untouched; cover.2026.avif becomes cover.2026.jpg, because only the last dot marks the extension; a name with no extension at all, attachment, becomes attachment.jpg; and a path such as shared/photos/beach.avif is reduced to its final segment, beach.jpg. The suffix seen earlier appears only when the name would not otherwise change — the misnamed scan.jpg, which becomes scan-converted.jpg.

How the output is verified

A download button on this site means the output has already been checked. The produced bytes are sniffed with the same detector applied to inputs: a JPEG opens FF D8 FF, and on a constructed head of those bytes the detector answers JPEG. Had the encoder produced something else — the PNG signature, say, which the detector reads as PNG — the disagreement with the planned JPEG would be reported as an error on the row, never offered as a mislabeled file. The blob is then re-decoded and its pixel dimensions compared with the canvas that was encoded; a disagreement there is an error too. Only a file that passes both checks is offered, and the size shown is that file's true byte count.

Where a row shows a percent change, it is computed from the two measured byte counts for your file, and the site publishes no blanket compression percentages anywhere, because no percentage is true for every image. The wording is the engine's. On invented byte counts — arithmetic, not an expectation for this pair — 150,000 bytes before and 1,380,000 after reads "820% larger — keep your original"; 2,000,000 to 2,090,000 reads "4.5% larger — keep your original", with one decimal because the change is under ten percent; 5,200,000 to 4,100,000 reads "21% smaller"; and 1,000,000 to 1,000,300 reads "less than 0.1% larger — keep your original", the engine's floor for a change that would otherwise round to nothing. Whichever direction your file measures, the row says it in the same breath as the download.

What the tool cannot know

The engine decides from formats, filenames and numbers, and it is plain about the edge of that. It cannot know whether your AVIF actually used its alpha plane, so it flattens every AVIF source onto the chosen colour and records the colour on the row; for a fully opaque photograph the composite changes nothing. It cannot know whether the first frame of an image sequence is the frame you wanted. It cannot predict the output size before encoding, which is why the row measures instead of estimating. It cannot say whether a given quality setting looks acceptable — it has no model of your eyes or of what the file is for, and this page offers no judgement of that kind; it tells you what was encoded, at what parameter, to what size, so that you can compare runs on your own file. And it cannot recover anything the AVIF or the JPEG pass discarded, or any metadata the re-encode dropped: your originals are the only copy of those.

Common misreadings

• "The slider is a percentage of the original's quality." It is the encoder's quality parameter, shown as a 0–100 readout of the engine's zero-to-one scale; the AVIF's own encoding settings are neither read nor matched.
• "A larger JPG means the tool failed." It means the measured output is larger. The row says so in the engine's wording — "820% larger — keep your original" on the invented counts above — and the conversion itself passed verification.
• "The flatten note means my image had transparency." The plan flags flattening for every AVIF source because the format can carry alpha; the note records the colour that was composited, not a finding about your pixels.
• "A .avif extension means the file is AVIF." The bytes decide. A misnamed file is converted from what it is, the row says so, and the output name follows the real content.
• "The orientation was lost with the metadata." The orientation tag was discarded, but it had already been applied during decode; the pixels come out upright.
• "Converting back to AVIF restores the original." It encodes the JPEG's pixels a further time, through the self-hosted libavif encoder at its own quality setting; nothing either pass discarded comes back.
• "The browser notice means my file is corrupted." The notice beneath the controls in the tool card is about this browser's decoder and is revealed only when the probe's decode fails; a file that will not decode produces an error on its own row instead.

Related tools

Keeping transparency or planning further edits? AVIF to PNG is the lossless landing place, with a plan whose flatten flag is no. Going the other direction, JPG to AVIF encodes with the self-hosted libavif + aom module — AVIF is a format this site both reads and writes, and asked whether it sits among the source-only formats (GIF, BMP, HEIC) the engine answers no. If the JPG then needs to meet a size limit, Compress JPEG runs the MozJPEG lane with its compress-to-target search (available on that lane). For the HEVC-coded sibling of this container, see HEIC to JPG, and for the two formats side by side, the HEIC and AVIF guide.

Frequently asked questions

Local processing: your images are decoded, converted, and verified inside your browser and never transmitted — see the methodology page for how to verify the no-upload claim yourself.