HEIC to JPG: Native Browser Support and Limits.

Reading and writing are separate capabilities

A converter needs to read the source and write the destination. A browser may display a common image format while lacking an encoder for it, or it may encode JPEG while being unable to read the particular HEIC file selected. A dropdown containing a format name is not evidence that both stages work.

Backdropless tests the actual image-decoding path and uses the browser’s JPEG encoder for the output. When decoding fails, the error explains that the browser cannot open the file. The source stays on the device. There is no hidden hosted conversion fallback and no renamed original passed off as a successful JPEG.

Why this is a limited feature

The project requires commercially usable permissive code in the shipped bundle. Some JavaScript HEIC wrappers have permissive wrapper licenses while embedding differently licensed decoding libraries. The wrapper’s headline license does not settle the license of the complete delivered package. This build therefore avoids bundling those decoders and relies on native support.

That choice makes capability depend on the browser and operating system. It is a real limitation, not a promise that every file from a phone will open. The tool page states the boundary before the user selects a source, and the unsupported path remains explicit when decoding fails.

Worked example: a supported local conversion

Choose the HEIC file in the converter. If the browser opens it, inspect the preview orientation and content, select JPEG and download a copy. Reopen the copy in the application that requested JPEG. Confirm that it is the intended photo and that its dimensions and visible appearance suit the destination.

If the source does not open, stop at that error and use a trusted native image application to export JPEG locally. Preserve the HEIC original. Renaming its extension does not transcode its contents, and uploading it elsewhere is a separate privacy decision that this tool does not make on your behalf.

Expect a new delivery image

A JPEG export is a new raster representation. Do not assume that every source metadata field, auxiliary image, depth record or editing history survives. The browser path is intended for an ordinary still image, not for preserving the entire source container as an archive. Keep the original whenever those additional records may matter.

JPEG is also opaque. If a source workflow includes transparency, the exported JPEG needs a background. Inspect the resulting file rather than judging success from the extension alone. The conversion should solve a compatibility problem without accidentally becoming the only remaining copy of a richer original.

Troubleshoot the right stage

A failure before preview points toward source decoding or input validity. A failure after preview but before download points toward the export path or device resources. Those stages deserve different messages and remedies. Repeatedly choosing another quality setting cannot fix a decoder that never opened the source.

The practical outcome is simple: either a real JPEG is created and inspected, or the user receives a clear limitation. That is more useful than an interface that advertises universal support while quietly changing the privacy or licensing assumptions behind the operation.