Can a HEIC file contain a virus? What is verified

Can a HEIC file contain a virus?

Not in the way an .exe or a macro-enabled document can. A HEIC is a photo container, and opening it means a program reads its bytes and draws a picture. Nothing in the format is executed. A file called photo.heic that is really a program does not become a photo, and a real photo does not become a program.

What can go wrong is the reading. Decoders are programs written for speed, usually in C or C++, that trust numbers inside the file: image sizes, offsets, counts. If a decoder checks one of them badly, a crafted file can make it read or write outside the memory it set aside. That is a memory-safety bug. It usually crashes the program. In the worst case an attacker turns it into code running inside the program that opened the file. It needs a vulnerable version, and vendors patch these when they are found.

Have HEIC and HEVC decoders had real vulnerabilities?

Yes. We read each record below on 12 October 2026 (NVD records through its CVE API, vendor pages in a browser) and describe only what the source says. “Patched” means the vendor says a later version fixes it, not that every device has installed it.

Two things stand out. Almost every entry needed someone to hand the program a crafted file, and the fix was a vendor update. And only two of the records above, both in Apple's ImageIO, came with a vendor statement that they may have been used in real attacks, in each case against specific people. We found no source saying HEIC files have been used in mass attacks. Absence in what we read is not proof it never happened.

Can a HEIC attachment infect my phone just by arriving?

In principle, yes, for the kind of bug above. Messaging apps decode images automatically to show a preview, so the file does not need to be tapped. Citizen Lab's 2023 report on BLASTPASS described an exploit chain delivered over iMessage as PassKit attachments containing malicious images, which compromised a device “without any interaction from the victim”. Apple fixed the image bug (CVE-2023-41064). Neither Citizen Lab nor Apple names the image format, so this shows the risk class and does not show a HEIC attack.

These were attacks on a few people, not a campaign against everyone. Apple's own page says Lockdown Mode is “designed for the very few individuals” who may be targeted, blocks most message attachment types, and that “most people are never targeted by attacks of this nature”. If you are at risk of that kind of attack (a journalist, an activist, a person under surveillance), Lockdown Mode exists for you. For everyone else the sensible defence is keeping the phone updated.

What can a malicious HEIC do, and what can’t it do?

• Can: crash the app that opens it, a thumbnail generator or a file picker. This is the usual outcome of a decoder bug, and CVE-2021-39804 above is an example.
• Can, if the decoder has a serious bug and is not patched: run attacker code with the permissions of the program that decoded it. That is the program, not the whole computer, and modern phones add further sandboxing.
• Cannot: start itself. Double-clicking a HEIC asks an image viewer to draw it.
• Cannot: do harm to software that already includes the fix.
• Cannot: hide a runnable program that the operating system will launch as a photo, because the extension only chooses which app opens it.

Is the real HEIC risk privacy rather than malware?

For most people, yes. A photo from a phone normally carries Exif metadata: when it was taken, the device, lens and settings, and, if Location Services was on, GPS coordinates. Apple's iPhone guide says plainly that sharing includes metadata such as location. That data is ordinary and intended, which is why nothing warns you. Anyone who receives the original file can read it.

• See what a file reveals with the EXIF and GPS viewer. It reads the file in your browser.
• Remove the location with Remove GPS, or all metadata with Remove HEIC metadata, before posting or sending a photo to someone you do not know.
• Converting to JPG does not by itself remove location. Our HEIC to JPG keeps date and camera details by default but leaves the location out unless you tick the box. In the run we did for this page, a sample with a GPS position converted to “Kept: date taken, camera · Location removed”.

Can renaming a file to .heic hide an .exe or malware?

Renaming changes a label, nothing else. We tested what our converter does with files that are not HEIC at all, each given a .heic name: a Windows executable header (“MZ”), an ELF header, a shell script, text, random bytes, zeros, a PDF, a ZIP, a JPEG and a PNG signature. None was opened as a photo, and none ran. Seven were refused as “not a HEIC/HEIF image”, and the JPEG, PDF and PNG stub as a file type the tool does not read. Two more, with a genuine HEIC header followed by junk, were refused as unreadable containers. This is what detecting a file by its contents, not its extension, looks like.

The reverse also happens: a real HEIC saved as .jpg, or a camera file with an unfamiliar extension. To see what a file really is, use the HEIC file checker, which reads the signature rather than the name, or the health check to find out whether it is damaged. Our HEIC vs HEIF page explains the brands inside the file.

Bytes added after the end of a valid picture are a different case. We appended a random megabyte, a script and an executable header to a valid HEIC. The converter decoded the picture, and the JPG it produced contained none of the appended bytes. The original file still carries them, but a decoder does not run them; they matter only to another program that is told to look.

Are HEIC email attachments dangerous?

The attachment is rarely the risky part. The message around it is. CISA says an unsolicited email asking you to download and open an attachment “is a common delivery mechanism for malware” and advises verifying a request by contacting the company directly using details you already have, not those in the message. The UK's NCSC says malware is often hidden in phishing emails or the sites they link to, and that well-set-up devices can stop it installing even after a click. We did not find a source documenting a campaign that uses HEIC attachments specifically.

• A photo you did not expect, from someone you do not know, with a prompt to log in, scan a code or reply urgently, is a phishing sign whatever the file type.
• A friend's photo arriving as .heic is normal: it is what iPhones save. A “.heic” that asks to be run, enabled or installed is not.
• If you clicked something, say so and report it. The NCSC's advice is that reporting is free and lets it take down scam addresses and sites.

How do I stay safe with HEIC files?

1. 01

   Keep the software that opens images up to date

   That is the OS (iOS, macOS, Android, Windows), your browser, and your photo apps. Decoder fixes ship in them. On Windows the HEIF Image Extension and HEVC Video Extensions are Store apps; Microsoft says the Store updates the first automatically. You can check the version with Get-AppxPackage -Name Microsoft.HEIFImageExtension in PowerShell.

2. 02

   Do not open files you did not expect

   A photo from a stranger or an unexpected “invoice.heic” gets no benefit of the doubt. Delete it, or confirm with the sender through another channel.

3. 03

   Open untrusted files somewhere contained

   A browser tab is a sandbox that a desktop viewer is not, and a converter that runs in the browser keeps the file away from your photo library. This lowers the damage a bug can do. It does not make a bug impossible.

4. 04

   Scan, but know what scanning catches

   Antivirus finds known malware. We found no source showing it reliably detects a crafted image aimed at a fresh decoder bug, so do not treat a clean scan as a guarantee. Updates are the control that works.

5. 05

   Strip metadata before sharing

   Use Remove GPS, or check first with the EXIF viewer.

6. 06

   If you may be a target, use Lockdown Mode

   Apple designed it for the very few people who may be personally targeted. It limits message attachments and other features.

Is an online HEIC to JPG converter safe?

It depends on where the conversion runs, and that is not something you can see from the page. Many converters upload your file to a server, decode it there and send a JPG back. That is not unsafe in the sense of a virus, but it means a copy of your photo, with its location data, passes through someone else's computers. Whether that matters depends on the photo, and on how far you trust the service's promises. We read what four well-known services say about their own handling:

A converter that works in your browser has a different risk profile, because the photo never leaves the device. That is an architecture claim you can test, which is the next section. A separate risk is the website itself: a look-alike domain, a pop-up asking you to install software, or a “free converter” program to download. A photo you upload to a website does not infect you; an installer you run can.

• Prefer a converter that says conversion happens in your browser, then verify that (below).
• Read the privacy policy for three things: is the file uploaded, how long is it kept, who can access it.
• Never install software to convert a photo when your operating system already does it. See HEIC to JPG on a Mac and opening HEIC on Windows.
• For photos with faces, documents or a home address, use an offline route or remove the metadata first.

How does heic.fyi handle your files, and what can you verify?

heic.fyi's tools decode HEIC with libheif compiled to WebAssembly, running in a Web Worker in your browser. The privacy page says files are read and transformed on your device and are not uploaded to a server for processing. The security page lists the controls. Here is what we checked ourselves on 12 October 2026, against this site's code and the live site.

A Web Worker is not, by itself, a network barrier: MDN notes workers can make requests with fetch. The barrier is the policy header above. WebAssembly adds a sandbox: its documentation says a module runs separated from the host and cannot escape except through approved APIs, and that direct code injection is not possible. It also says bounds checking is “at the region level”, so an overflow can still overwrite adjacent data in the module's own memory. In plain terms, a decoder bug here would be contained to the browser tab's sandbox, but it could still corrupt what the decoder is working on.

How do you check a converter yourself?

1. 01

   Open the browser's developer tools on the converter page

   In Chrome, Edge or Firefox press F12 and choose the Network tab. In Safari, enable the Develop menu in Settings first.

2. 02

   Clear the log, then convert a photo

   Look for requests whose method is POST or PUT, or whose size is close to your photo's. A converter that uploads will show one. Requests for scripts, WebAssembly files and the page itself are ordinary downloads.

3. 03

   Try the offline test

   Convert one file so the converter has loaded, switch Wi-Fi off (or set the Network tab to Offline), then convert another. A tool that processes on your device keeps working. One that needs a server stops.

4. 04

   Remember what it cannot show

   The Network tab shows what the page sent during your test. It does not prove what a site will do next week, and a page could keep a copy for later. Reading the policy and choosing sites you trust still matter.

How does the converter treat hostile files?

Before a file is decoded we apply limits, and every one of them fails with a clear message rather than running to exhaustion. These are the values in the code.

The libheif build we ship has its own limits as well, and we saw them working. For example, it refused one damaged file with “Number of extents in iloc box (65535) exceeds security limit (32)” and another because a box claimed a size of 2^62 bytes. Its default cap on image size is 2^30 pixels (about one gigapixel), which we read from the module; our own cap is ten times lower. Our own HEIF parser, used by the Inspector and the metadata tools, is TypeScript and bounded: at most 4,096 boxes, nesting depth 8, 4,096 items and 2,048 properties. A bug in JavaScript can throw an error or waste time but cannot corrupt memory the way C code can.

To see how this behaves, we built 159 hostile files from our own CC0 sample files and ran each through the real converter page in headless Chromium: truncations, random damage in the metadata, parameter sets and pixel data, forged size and offset fields, files of the wrong type, and a 101 MB file. They are random damage and forged numbers, not working exploits. The corpus script is scripts/benchmarks/heic-security-corpus.py and the runner is heic-security-stress.mjs.

0

tab crashes, hangs or uncaught page errors

across 159 files

0

requests carrying file data

only Google Analytics page_view events, no body

0.9 s

slowest file

median 0.13 s; 101 MB file refused in 0.2 s

1

known-good photo converted afterwards

the worker was still healthy

What this does not show. The damage was random or hand-forged, not coverage-guided fuzzing, so it would not find a bug that needs a precise bitstream. We did not try the proofs of concept behind the CVEs above, which we did not have. It tested the HEIC to JPG route and the Chromium engine. It is useful evidence that failures are clean and bounded, and it is not a proof of safety.

What can’t we promise?

We cannot say our converter is 100% safe, and nobody can say it of a decoder. Here is the specific position as of 12 October 2026, so you can judge it. We read the versions from the WebAssembly module itself: our build uses libheif 1.23.5 and libde265 1.0.15. We updated libheif from 1.23.2 on the same day after checking that decoded pixels were unchanged on our test files. The libheif project's releases page now lists 1.23.6, so we are one release behind there. libde265's latest release is 1.1.3, and that is the larger gap.

What that means. These are bugs in code that parses an untrusted HEVC stream, which is what a HEIC contains, so a crafted file aimed at one of them could in principle crash our decoder or corrupt its memory. It runs in a WebAssembly sandbox inside a worker whose script can connect only to our own origin, which limits what a bug can do and where data could go. It does not make a bug impossible, and the sandbox is not a reason to be casual. If your photo is sensitive and its source is not trusted, a tool you have no reason to doubt does not change the first rule: update your own software and do not open files you do not trust.