SD card corrupted causes almost never arrive one at a time. The message on the rear screen is the last link of a chain that usually started hours earlier, when a card was pulled from a reader without being ejected, or when a camera lost power in the middle of a write. The most useful action at that moment is the counterintuitive one: do nothing. Decline the format prompt, because accepting it is the step that converts a recoverable situation into a permanent one.
Below is that chain, link by link — what has actually changed on the card at each stage, what the camera can and cannot see, and the single action that stops the next link from forming.
Confusing “corrupted” with “damaged”
A camera does not write a photo. It writes a photo, then a chain of allocation records, then a directory entry that points at that chain. Every manufacturer implements this the same way, because the card carries a file system that both the camera and your computer have to read.
- The file allocation table records which clusters belong to which file, and in what order. On cards of 32 GB and below this is usually FAT32; above that, exFAT. The table is the map.
- Directory entries record each file’s name, size, capture timestamps, and first cluster. The entry is the label.
- Corruption, in the sense a camera means it, is the two disagreeing. The table says a file owns clusters 4,000 through 4,120; the entry claims 12 MB; a host that reads both can sometimes reconcile the mismatch and sometimes cannot.
That definition matters more than it sounds, because it means the word “corrupted” is describing bookkeeping, not substance. The pixels, the audio, and the GOP structure are exactly where the camera left them. Nothing has rotted. Every link after this one is a reaction to a mismatch in metadata, and reactions are where data is actually destroyed. The structural background belongs to a separate topic — if you want the layout of clusters, tables, and root directories, the explanation of what file system cameras use covers it without the alarm.
Link one: the write never finished cleanly
Every chain begins with an interrupt, and the interrupt is usually mundane. The card came out of the camera or the reader while the access light was still on. The battery was swapped at 2 percent. The camera was switched off before it finished writing the last clip, or the door of a drone’s battery bay was opened while the aircraft was still flushing its buffer.
Cameras buffer writes rather than committing them immediately. A still photo is committed within a fraction of a second, but a video clip is a long-running transaction: the camera appends data clusters continuously and only updates the table and directory entry at intervals. That design creates two very different failure outcomes, and the difference is the first place where people misdiagnose their own situation.
If the interrupt lands before the transaction starts — the file exists in the buffer, nothing has been written — the file is simply absent. The card is perfectly healthy. If the interrupt lands between the data and the metadata, the card holds a chain of clusters with no valid entry pointing at it, or an entry pointing at a chain that is incomplete. The first case is a missing file. The second is structural inconsistency. The second is far rarer and much worse, and it is the one that produces a “corrupted” card rather than an empty slot in a folder.
The behavior behind this is documented in the note on pulling a card without ejecting it, and the power-loss variant is covered in the analysis of power loss during recording.
Link two: the table and the directory entry fall out of sync
This link is where the damage becomes self-sustaining, because both structures have a copy and the copies no longer agree.
FAT32 keeps two copies of the allocation table, and exFAT keeps one table plus a backup boot region. The intent is redundancy: if one copy is unreadable, a host can fall back to the other. The mechanism fails in a specific circumstance — when the write is interrupted between updating the primary and updating the backup. Now the two structures on the card describe two different file layouts, and there is no way for a host to know which is authoritative without external information.
Three concrete states follow:
| State of the metadata | What the camera sees | What is physically true |
|---|---|---|
| Entry valid, chain complete | Normal file | Normal file |
| Entry valid, chain broken partway | File listed but unreadable or truncated | Data clusters present, chain lost |
| Chain complete, entry missing | File absent from the folder | Data clusters present, unindexed |
| Entry and table describe different files | “Card error” on mount | Both files’ clusters present, ownership ambiguous |
The third row is the important one and the most commonly misunderstood. A file can lose its directory entry entirely while every byte of it remains on the card. It stops existing as far as any file manager is concerned, and it stops existing as far as the camera is concerned, but the storage medium has not been touched.
Link three: the camera refuses to mount the volume
Cameras do not run desktop-class repair. The firmware attempts a minimal mount — read the boot region, read the root directory, confirm that the structures are coherent enough to write into — and if any step returns something it cannot interpret, it aborts the mount rather than guessing.
That abort is what produces the message you saw. It is not a diagnosis. It is a statement that the camera cannot safely write to the volume, delivered by a device that has no way to tell you which of the four states above it encountered. The same screen appears for a completely recoverable metadata inconsistency and for a card whose controller has failed outright, which is exactly why the on-screen text is nearly worthless as a diagnostic; the reading of those messages is broken down further in the guide to the camera card error message.
Because the camera cannot repair, it offers the only operation it has: format the volume. That offer is not a repair recommendation. It is the firmware acknowledging its own limits.
Link four: accepting the format is the point of no return
Here is the first genuinely counterintuitive link in the chain. Formatting a card in a camera almost never erases the data. It rewrites the boot region and the empty tables, then marks the previous clusters as available. Every photograph that was on the card is still physically present after the format finishes.
What the format destroys is the map, and the map was the last surviving index. Before the format there were two ways to reach the files: parse the surviving metadata, or scan the medium for recognizable file structures. After the format, only the second path remains, and it is a strictly harder problem — file names, folder hierarchy, and some metadata are typically lost, and fragmented files become difficult or impossible to reconstruct. The difference between an in-camera operation and what a computer does to the same card is substantial and is compared in the breakdown of in-camera format versus computer format.
So the format does not destroy the data, but it removes the only cheap route back to it. That is why “decline the prompt, copy the card first” is the correct action at this link rather than a cautious suggestion. The page on recovering photos after formatting an SD card describes what is still achievable once this link has been crossed — a real recovery, with real limits.
Link five: continued shooting overwrites the survivors
The final link is the one that ends the story, and it is created by the previous link rather than by the original fault.
After a format, the allocation table says the entire card is free. The next recording therefore does not merely consume unused space — it is handed the clusters that hold your older files, starting from the beginning of the volume. There is no preference for genuinely empty areas, because after the format there are no marked-as-used areas at all.
Memory cards do not work like solid-state drives in one respect that matters here: they have no TRIM command, and no background garbage collection that zeroes or recycles freed blocks, so a deleted file is not quietly erased by the card itself. Recovery prospects therefore stay alive for as long as the card is left alone — and collapse the moment it is filled with new material. The mechanics of what survives are set out in the discussion of accidental deletion and formatting.
Once overwritten, the clusters genuinely are gone. No software recovers them, and no laboratory recovers them either — the charge states have been rewritten with new data. This is a limit of physics rather than of tooling, and it is why every instruction on this page reduces to one sentence: stop writing to the card.
The correct move at each link
| Link you are on | What has changed | Correct action | Recoverability |
|---|---|---|---|
| 1. Interrupted write | Last transaction incomplete | Stop using the card; do not re-insert it and resume shooting | High |
| 2. Metadata out of sync | Table and entries disagree | Copy the card as an image before anything else | High |
| 3. Camera refuses to mount | Firmware aborted the mount | Move to a computer; do not format on the camera | High |
| 4. Format accepted | Map destroyed, data intact | Write nothing new to the card | Medium to high |
| 5. Card returned to service | Old clusters handed to new recordings | Nothing remains to attempt on overwritten areas | Overwritten portion: none |
The pattern running down that column is the point of the whole page. Every link is survivable, and every link is made fatal by an action taken at the next one.
Causes that sit outside this chain
Not every dead card is on this chain, and misreading a hardware failure as a metadata problem wastes the window when recovery is still possible.
Physical damage, water exposure, and controller failure are different categories. A card with a cracked substrate, oxidized contacts, or a controller that can no longer build a block map will not respond to any software, and the only route is a data recovery laboratory working at the chip level. The distinction between the two families of failure is the organizing idea behind why camera files get corrupted, and the point at which the situation stops being a software problem is defined in the notes on unrecoverable data.
There is one trap in this boundary. A failing controller often presents itself first as file-system corruption, because writes that the controller claims succeeded were not written reliably. If a card has produced metadata errors more than once, or if problems follow it between readers and computers, treat it as a hardware case and prioritize getting the data off it — not as a card worth repairing and reusing.
Recovering from the link you are standing on
Work from a copy, always. If the card still appears to a computer as a drive, image it first with a tool such as dd or a disk imager, and run every subsequent attempt against the image rather than the original. The card is failing hardware in the general case, and every additional scan is another opportunity for it to fail completely.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive. Expect two passes: one that reads whatever file-system structure survived, which preserves names and folders, and one that carves by file signature, which recovers files the structures no longer describe but usually without their original names.
Files that come back without a name are not damaged files. A JPEG begins with the bytes FF D8 FF and a video container declares its own structure in a header, which is exactly how signature-based scanning finds them after the index is gone.
Frequently Asked Questions
Does a corrupted SD card mean my photos are gone?
Usually not. Corruption in this context is a metadata fault, so the image data normally remains on the card and is recoverable. The exception is content that has since been overwritten by new recordings, which no tool or laboratory can restore.
Can I repair a corrupted card without losing the files?
Sometimes the volume can be rebuilt so the card works again, but any repair utility writes to the card and can destroy the metadata that a recovery pass needed. Recover first, repair second, and never run a repair on the only copy of irreplaceable work.
Why does my camera offer to format instead of fixing the card?
The firmware mounts volumes by checking their structures and aborts when they are inconsistent. Formatting is the only write operation the camera has, and it produces a volume the firmware can mount. It is a device limit, not a recommendation.
I already formatted the card. Is everything lost?
No. An in-camera format rewrites the metadata and marks the clusters free; the files themselves remain until new recordings consume those clusters. Stop shooting on that card, image it, and scan the image rather than the original.