Why Your CR3 File Won't Convert (and How to Fix It)

Message: Please upload CR3 files (.cr3 extension).

The converter checks the extension before it reads a byte, so this is a filename problem rather than a content problem. Four things cause it.

It is a CR2. Canon used CR2 until 2018 and CR3 after. If your body predates the EOS M50, everything on the card is CR2 and needs a different route — most raw editors and Microsoft's Raw Image Extension read CR2 happily.

It is a CRM. Cinema RAW Light video files come off Canon's video-capable bodies with the .CRM extension. They are footage, not photographs, and no still converter will take them; you need Canon's Cinema Raw Development software or an NLE that supports the format.

It is a HIF or HEIF. Some recent Canon bodies can shoot HEIF stills instead of JPEG. Those are not raw files at all and go through an ordinary image converter.

Someone renamed it. Adding .cr3 to a filename does not change what is inside. If a file arrived already converted, or was renamed to "make it work", the extension is now lying and the check is right to refuse it.

Message: No embedded image found — this file may not be a Canon CR3.

This one means the extension was accepted, the file was parsed as a container, and the full-size JPEG the camera should have written was not in it. That is a much more specific failure, and it narrows the cause considerably.

The usual explanation is that the file is not a Canon still raw despite its name — a container from a different device, or a file that has been through software which rewrote it and dropped the previews. Some conversion and archiving pipelines strip embedded previews to save space, which is helpful for storage and fatal for this approach.

It can also mean the file is truncated: the container's structure is at the start, the image data comes later, and a copy that stopped early parses fine right up to the point where the picture should be.

What to do: open the file in a raw editor. If Digital Photo Professional or darktable displays it, the raw data is intact and only the preview is missing — export a JPEG from there. If the editor also refuses, treat it as the corruption case below.

Message: This image is too large for your browser to render. Try a smaller output resolution.

This is a browser limit, not a file problem, and it is the one failure here with a one-click fix.

Browsers cap the total area of a canvas they will allocate, and the ceiling varies by browser, platform and available memory — mobile Safari is considerably stricter than desktop Chrome. A full-resolution frame from a high-megapixel body plus the memory needed to encode it can cross that line. The converter already steps the size down and retries before giving up, so seeing this message means even the reduced attempts did not fit.

Fixes, in order of how little they cost you:

1. Set the output size to 75 or 50 percent. For most uses the smaller file was the better choice anyway.
2. Convert fewer files at once. Memory pressure from a long queue makes the ceiling easier to hit.
3. Close other tabs, particularly anything heavy.
4. Move to a desktop browser if you started on a phone.
5. If you genuinely need full resolution, develop the file in desktop raw software instead — it has no canvas limit to respect.

Message: The embedded preview could not be decoded — or a failure in every piece of software you try.

If a raw editor also refuses the file, the problem is the file. Three causes account for most of it.

An interrupted transfer. Pulling a card reader out mid-copy, or a network share dropping, leaves a file with the right name and a plausible size that stops partway through. This is the most common and the easiest to fix: copy it again from the card, assuming the original is still there.

A failing card. Cards fail, usually gradually and usually in ways that damage a handful of files rather than all of them. The tell is exactly that pattern — most of a shoot converts and three frames refuse. Stop writing to the card, copy everything off it, and retire it.

Interrupted writing in camera. A battery pulled during a burst, or a card removed while the access light was on, can leave the last frame incomplete.

If the original on the card is also damaged, recovery is a specialist job with variable results. What is worth doing first: compare the copy against the original with a checksum. If the hashes differ, the copy is at fault and re-copying will fix it. If they match, the damage is on the card and the copy is faithful.

A batch where most files succeed and a few fail is diagnostically useful, because it rules out the whole category of "the tool does not work" and points at the individual files.

Failures are reported per file and finished work is kept, so the practical approach is to let the batch run, note which frames failed, and treat those individually against the sections above. In rough order of likelihood: the odd frames are a different format that slipped into the folder, they are the truncated tail of an interrupted copy, or they are the damaged frames from a card that is starting to go.

One pattern worth naming: if the failures are all the last files in a shoot, suspect the transfer rather than the card. If they are scattered through it, suspect the card.