JPG to AVIF Converter

Why AVIF — and why not HEIC

AVIF and HEIC are structurally siblings — the same HEIF container around a modern video codec — but they live under opposite legal regimes. HEIC's HEVC codec is covered by commercial patent pools, which is why browsers do not ship HEVC encoders and why this site's libheif build is decode-only: producing HEIC files would require licensing terms that a free, in-browser tool cannot honestly satisfy. AVIF's AV1 codec was developed by the Alliance for Open Media to be royalty-free under an explicit patent grant, which is why every current browser reads it and why this site is comfortable shipping an encoder for it. Practically: HEIC-class compression, or better, in a format the web actually reads — so conversions here go from HEIC and to AVIF, never the reverse. The guide HEIC and AVIF: decoding and licensing follows that story through both halves — how the same box parser tells the two apart, and what each decoder and encoder is licensed under.

The honest details

• Measured, not promised: every row shows real input bytes, real output bytes, and the computed percent change — including "larger — keep your original".
• Quality slider only: no target-size mode on this lane, because a measured single encode of a detailed 12 MP photo takes ~5 seconds — a binary search over eight encodes would be dishonest UX. The Compress JPEG tool has the target-size mode, where encodes are fast.
• Metadata is stripped: EXIF — including GPS location — does not survive the re-encode. A privacy win for sharing; keep your originals.
• Encoded by libavif + aom locally: libavif with the aom AV1 encoder (BSD-2-Clause, under the AOM patent grant), compiled from pinned upstream source to WebAssembly, self-hosted by this site, and running in a bounded worker only in your browser. Details on the methodology page.
• Verified output: every AVIF is re-sniffed and re-decoded before its download button appears.

The sections below open each of those claims up for this pair: what the detector reads from a JPEG, what the planner decides, what the encoder is, what the re-encode strips, and how the result is checked. Every figure is computed at build time by the engine that processes your files, on illustrative inputs named as such.

What the detector sees

The first thing this lane does with a dropped file is read its leading bytes and run them through the content detector every tool on the site uses. JPEG's signature is the three bytes FF D8 FF, and the detector matches exactly those. The byte arrays in this section are illustrative, constructed in this page's frontmatter to begin the way a file begins and nothing more. Handed an illustrative four-byte array FF D8 FF E0 at build time, it returns JPEG; handed the constructed FF D8 FF E1, it returns JPEG; handed the bare three-byte signature, it still returns JPEG. The fourth byte is not consulted, so the detector makes no distinction between the two markers that commonly follow the signature and no claim about what the segments after them hold. Handed only a constructed FF D8, the same detector returns unrecognized: a file cut off inside its own signature is reported as unrecognized rather than guessed at.

The filename's extension is checked second and separately, and the extension map reads .jpg, .jpeg and .jfif as claims of JPEG. Because the lane goes by the verdict and not the claim, three illustrative misnamed cases — invented names over the constructed arrays above — behave as the bytes dictate. A JPEG body named IMG_2231.heic comes back from the check as actual JPEG, claimed HEIC, mismatch yes: the row shows the notice and converts it as the JPEG it is, naming the download IMG_2231.avif. A JPEG body named poster.avif is actual JPEG, claimed AVIF, mismatch yes — converted too, and named poster-converted.avif, because swapping the extension would otherwise reproduce the input name and the download would shadow your original. Going the other way, a PNG body named photo.jpg is actual PNG, claimed JPEG, mismatch yes; this lane converts JPEG sources only, so the row names the format the file actually is and points to the converter that takes that format to AVIF rather than encoding under a false label. An illustrative file with no extension at all, scan, carrying the same constructed JPEG bytes is actual JPEG with no claim to compare, so its mismatch flag is no and it converts without a notice. The other signatures are in how image formats are detected.

The plan for this pair

Before a pixel is touched, a pure planning function decides what the conversion will do, and the figures here are its actual return values for JPEG to AVIF with this page's defaults. The output MIME type is image/avif. Flatten over a background: no — and that answer holds for two independent reasons. The AVIF target's alpha capability in the engine's table is true, so the target never forces a flatten; and JPEG is not among the source formats the planner treats as alpha-capable, so a JPEG source never triggers one either. The engine's plan for JPEG to JPEG, the one target that cannot hold transparency, also answers no, where PNG to JPEG answers yes. The plan still carries a background field (#ffffff), but nothing on this lane reads it, and no colour picker appears above. First frame only: no — JPEG is not among the containers the planner treats as animatable, so no caveat is shown.

The reverse plan, AVIF to JPEG, shows how asymmetric the pair is: there the flatten flag is yes, because a HEIF image can carry an alpha auxiliary plane and JPEG cannot hold one; the first-frame flag is yes, because the avis brand makes AVIF an animatable container; and the default quality is the JPEG target's 92. None of those three applies on the way in.

Quality is 0.5 on the engine's quality scale, which the quality mapper turns into 50 on the whole-number scale from 0 to 100 that the encoder takes — the number the slider shows before you touch it, and libavif's own default as the engine records it. Moving the slider changes that one field and nothing else: at an illustrative slider position of 30, the plan's quality is 0.3 and the encoder receives 30 back; at the slider's top it is 0.95, encoder 95; at its floor 0.05, encoder 5. The slider runs from 5 to 95. The planner validates rather than clamps: asked for an illustrative 1.5, above the top of its scale, it refuses with "Quality must be between 0.05 and 1.". The scale and what it is not — a percentage of anything — are covered in quality parameters and compress-to-target.

The output name swaps the extension for the target's canonical one, .avif, and leaves the stem alone. On illustrative names: holiday.jpg becomes holiday.avif; photo.jfif becomes photo.avif; IMG_4821.JPEG becomes IMG_4821.avif, because extension case is ignored; DSC_0042.final.jpg becomes DSC_0042.final.avif, because only the last dot counts. Each is the naming function's return value for that invented name, computed when this page was built.

The encoder: libavif + aom, running in your tab

Decoding the JPEG uses the browser's own codec via createImageBitmap with imageOrientation: 'from-image', which applies EXIF rotation so phone photos come out upright. The pixels are drawn to a canvas and read back as a plain RGBA buffer, and that buffer — not the JPEG's own compressed data — is handed to the worker, so the AVIF is a fresh encode of the pixels rather than a re-wrapping of the file. The browser's canvas encoders produce PNG, JPEG and WebP; AVIF output comes from one of the two self-hosted encoders on the site. This page encodes with libavif (© Joe Drago and contributors) driving the aom AV1 encoder (© Alliance for Open Media), both BSD-2-Clause, under the royalty-free Alliance for Open Media Patent License. The hardened browser binding is derived from Google's Squoosh/jSquash wrapper under Apache-2.0. License and patent-grant texts ship alongside the module at /vendor/avif/LICENSE.txt, /vendor/avif/LICENSE-libavif.txt, /vendor/avif/LICENSE-aom.txt, and /vendor/avif/PATENTS-aom.txt.

The codec is compiled from pinned upstream source, served from this site's own origin as separately replaceable files, fetched lazily only when a file is actually dropped, and run in a bounded worker entirely in your browser. Every vendored file's exact size and SHA-256 is pinned by automated tests, and every codec build uses immutable upstream commits, so the served bytes cannot drift silently. One engine constant shapes the encode: the lane's speed preset is 8, chosen on measured encode time in a single-threaded build, and each row reports how long its encode actually took on your device. The decoder side of this story — why HEIC needs a self-hosted decoder while AVIF uses the browser's own — is the subject of HEIC and AVIF: decoding and licensing; the canvas path shared by every lane is in the conversion pipeline.

Why there is no "fit under N KB" control here

The JPEG lanes offer a target size, solved by measurement: encode at maximum quality, then binary-search the quality range, converging within eight encodes. Whether a lane offers that search is an engine flag. For the MozJPEG lane behind Compress JPEG the flag reads yes; for this AVIF lane it reads no. The reason is recorded beside the constant: a single encode of a detailed 12-megapixel photo takes around five seconds in the single-threaded build, so a search of up to eight probes would run tens of seconds per file. Rather than hide that behind a progress bar, the page offers the quality slider only, and each row reports the quality it used and the time the encode took. A JPG that must land under a size limit is a job for Compress JPEG, where the search is on — and because the source is already a JPEG, that route changes no format. On the illustrative name holiday.jpg, the JPEG-to-JPEG plan's flatten flag is no and its first-frame flag is no, the same two answers as here, and the download is named holiday-compressed.jpg: when the extension would not change, the naming function adds the suffix that lane passes it, so the download cannot shadow the original.

What re-encoding strips

Because the output is a fresh encode of decoded pixels, everything stored beside the pixels is gone: EXIF (including GPS location, camera model, and timestamps), colour-profile tags, and, for formats that carry them, text chunks. The site presents this as both a feature and a caveat, because it is both — publishing a converted photo cannot leak where it was taken, and equally, photographers lose copyright fields and ICC profiles, so originals should be kept. Orientation is applied during decoding, before metadata is discarded, so uprightness survives even though the orientation tag does not. One more thing does not come back: the encoder receives the decoded pixels and nothing more, so whatever the JPEG's own compression discarded before the file reached this page is not available to it. The AVIF target's lossy flag in the engine's table is true: every output is a lossy encode, at every slider position, of pixels that were themselves decoded from a lossy JPEG. The full account is in what re-encoding does to metadata.

How the output is verified

A download button on this page means the AVIF has already been checked twice. First, the produced bytes are sniffed with the same magic-byte detector applied to inputs. AVIF is recognized by parsing the ISO-BMFF ftyp box — the major brand and every compatible brand read from the box structure, bounded by the declared box size, never by substring-searching the file — and looking for the avif or avis brand. An illustrative header built in this page's frontmatter, with major brand avif and compatibles mif1 miaf, is read back by that parser as the brand list avif mif1 miaf and classified AVIF, so the check passes: yes. The same header reports no for the image-sequence check, since no avis brand is present. Had the encoder produced bytes beginning FF D8 FF instead — the illustrative JPEG array from the detector section, handed to the same check at build time — the detector would classify them JPEG and the check would pass: no — reported as an error, never offered as a mislabelled file.

Second, the blob is re-decoded and its pixel dimensions compared with the plan; a mismatch is an error too. On this lane that re-decode goes through the browser's own AVIF decoder — the engine's native-only decode list is AVIF, the one format it decodes but ships no fallback for — so verification relies on the same native support the AVIF to JPG page does; in the methodology page's words, current Chrome and Edge, Firefox 93+, and Safari 16.4+ decode AVIF natively.

The sizes on a row are the two blobs' true byte counts, and the percent beside them is computed from those two numbers alone. The display rules are the engine's, and rather than restate its thresholds this page lets the engine exhibit them on invented byte counts — arithmetic to show the rules, not a figure to expect from any real photo. On this lane the first count is a JPEG's bytes and the second an AVIF's, but the arithmetic knows nothing of formats. 2,457,600 bytes becoming 614,400 reads "75% smaller" — a large change, shown as a whole percent. 1,000,000 becoming 964,000 reads "3.6% smaller" — a small change, shown to one decimal place. 1,000,000 becoming 999,800 reads "less than 0.1% smaller" — a change below the smallest figure the display shows. 95,000 becoming 102,600 reads "8% larger — keep your original" — growth stated as plainly as shrinkage, with the advice attached. Two identical counts read "same size". The site publishes no blanket compression percentages anywhere, because no percentage is true for every image.

What the tool cannot know

• Whether your AVIF will be smaller. Only encoding tells. When the result is larger the row says so, and the original is the file to keep.
• How the JPEG was saved. The detector reads the three signature bytes and stops; it has no view of the quality or the settings the file was written with, which is why the slider starts at the same 50 for every file.
• Whether the loss is acceptable for your purpose. The slider is a parameter the encoder takes, not a verdict this page delivers; it attaches no judgement to any value, and the only honest test is your own eyes on your own photo.
• Where the file is going. This page cannot check whether the destination you have in mind reads AVIF. If it turns out not to, AVIF to JPG is the way back.

Common misreadings

• "The percent on my row is what AVIF saves." It is what this encode saved on this file, computed from two measured byte counts — the JPEG's and the AVIF's. The next photo can land anywhere, including larger.
• "Quality 50 means half the quality of my JPG." It is a position on the whole-number scale from 0 to 100 that the encoder takes — the position libavif defaults to, as the engine records — and the engine's quality of 0.5 mapped onto it. It is not a percentage of the source, and the page says nothing about what any position looks like.
• "The top of the slider keeps the JPG as it was." No position on this lane is lossless: the target's lossy flag is true at every quality, and the encoder starts from decoded pixels, not from the JPEG's data.
• "I should be able to set a target size, like Compress JPEG." That lane's search flag reads yes; this lane's reads no, on the measured encode time recorded beside the constant. A JPG that has to meet a limit goes there and stays a JPEG.
• "My AVIF still has the photo's location in it." It does not. The re-encode strips the JPEG's EXIF, GPS included; only the applied orientation survives.
• "It takes seconds, so it must be uploading." The seconds are your own processor encoding AV1 in a worker inside the tab. The encoder is fetched from this site's origin, and the page's connect-src 'self' policy stops scripts here from sending data anywhere else — the methodology page shows how to watch the Network tab and confirm it.
• "AVIF is HEIC under another name." Same container family, which is why one box parser detects both, but a different codec with different brands and different licensing — the reason this site decodes HEIC and encodes only AVIF.
• "A .jpg is a JPEG." The bytes decide. A misnamed file is reported as what it is: converted if it is a JPEG; reported as PNG with a pointer to PNG to AVIF, the one other lane that encodes AVIF, if it is a PNG; and for any other format, reported as what it is and taken no further on this page.

Related tools

Transparency to preserve? PNG to AVIF keeps alpha intact. Going the other way — an AVIF a form will not accept — AVIF to JPG and AVIF to PNG decode with your browser's own codec. If you need to stay in JPEG, Compress JPEG squeezes the format as far as it goes. The guides explain the engine behind every lane.

Frequently asked questions

Local processing: your photos are converted and verified inside your browser and never transmitted. AVIF encoding by libavif and aom, BSD-2-Clause, self-hosted and used unmodified — see the methodology page for full attribution and how to verify the no-upload claim yourself.