Why Your Image Upload Works With JPG but Fails With HEIC
A profile-photo form works perfectly with your JPG test image. Then someone selects a photo from their iPhone, and the preview stays empty. The file may be perfectly valid. Your upload workflow may simply depend on imag
A profile-photo form works perfectly with your JPG test image. Then someone selects a photo from their iPhone, and the preview stays empty.
The file may be perfectly valid. Your upload workflow may simply depend on image support that is different from the support on the user's device.
HEIC makes this easy to notice. A photo can open normally in one application and fail at a later step in another. Fixing the experience starts with identifying which step actually failed.
Selecting a file does not mean the browser can decode it
A typical file input looks straightforward:
<label for="photo">Choose a photo</label>
<input id="photo" name="photo" type="file" accept="image/*" />
The accept attribute helps guide the file picker. It does not add an image decoder, convert a selected file, or validate its contents. MDN describes it as a hint for file selection, with validation still required on the server when files are uploaded.
Your application can receive a file and still be unable to display it in a preview or open it in a crop editor.
Native HEIC support also varies across browsers and platforms. For example, WebKit added HEIC image support in Safari 17. That is a reason to test the environments your application supports rather than assume that every browser behaves like your development browser.
Find the failing stage before changing the input
An image upload often contains several separate operations:
| Stage | What needs to work |
|---|---|
| File selection | The picker or drop area returns a file |
| Preview or editing | The browser or an added decoder can read the image |
| Server processing | The deployed image pipeline can validate and process it |
| Displaying the result | The saved image can be viewed by its intended audience |
A failure in any row can look like "the upload is broken."
If the preview fails before any request is sent, changing server upload limits will not address that failure. If the file reaches the server but thumbnail generation fails, investigate the processing stage and its supported formats.
Keep preview errors separate from network and processing errors. A message such as "We couldn't preview this image format. Try a JPG or PNG copy" gives the user a useful next step when those are the formats the application supports.
"Upload failed" leaves them guessing whether they should retry, choose another photo, or check their connection.
Treat filenames and MIME types as clues
Renaming photo.heic to photo.jpg does not turn it into a JPEG. The encoded image data still needs to be decoded and written in the destination format.
The browser's reported MIME type is another clue, with limitations. A File inherits its type property from Blob; MDN notes that the value can be empty or inferred from the extension, rather than established by reading the file's bytes.
Use those values to guide interface messages and routing decisions. For an upload endpoint, verify the received content with processing tools that support the formats you intend to accept.
A renamed file is also a useful test case: it helps reveal whether your application confuses a familiar suffix with a decodable image.
Choose an explicit HEIC policy
There are several reasonable ways to handle HEIC, depending on the product.
An application built around photo uploads may benefit from integrated conversion. That requires a deliberate choice about where decoding happens, which environments are supported, and how failures are reported.
A simpler form may accept a smaller set of formats. In that case, state the accepted formats before selection and provide a clear recovery path when a user supplies something else.
For an occasional task, such as preparing photos for a CMS that requires JPEG, creating JPG copies before uploading can be practical.
The important product decision is whether HEIC is supported throughout the workflow. Allowing selection without a plan for previewing, processing, or explaining the limitation leaves the user to discover the boundary.
Preparing JPG copies for an existing website
Disclosure: I'm building CompressFly. Its HEIC to JPG converter is one option for preparing compatible copies when the destination requires JPEG.
It accepts HEIC and HEIF images, offers adjustable JPG quality, and supports individual files or a batch:
- Add photos with Select images, Select folder, or drag and drop.
- Keep JPG as the output format and choose the image quality. The current default is 90%; try a few representative photos before processing a large folder.
- Start conversion, review the results and output sizes, then download individual JPGs or the completed results together in a ZIP.
Conversion runs locally in the browser, so the source photos are not uploaded to a conversion server. The website still needs to load its application resources, and processing uses the device's memory and computing resources.
After downloading, open a JPG and try it in the actual destination. That checks the workflow you needed to complete.
Conversion solves compatibility; check size and appearance separately
HEIF is designed for efficient storage. Apple's HEIF compatibility guide explains both its storage advantages and the use of more compatible formats when sharing.
A JPG copy can therefore be larger than the HEIC source. Converting the format alone does not guarantee that the file will fit an upload size limit.
JPEG also uses lossy compression, as described in MDN's image format guide. A higher quality setting can help preserve visible detail, but the conversion should not be described as lossless.
Check fine detail, orientation, and appearance in the downloaded result. If your workflow depends on particular metadata, verify that separately instead of assuming it survived conversion. Keep the HEIC originals for future editing or archiving.
Add real phone photos to your test set
Before calling an image upload complete, try:
- A real HEIC photo and a JPG copy of the same image.
- File-picker selection and drag and drop, where the application offers both.
- The browsers and devices your users actually use.
- A file that has been renamed without being converted.
- The full path from selection through preview, processing, and the final saved image.
For a browser that cannot preview an accepted format, check that the interface still gives an understandable result and a recovery path.
A reliable photo upload should make its format requirements clear and help users finish the task when their original photo needs conversion.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.