If you want to know how do cameras store photos, the short answer is that the image never touches a “file” until the very end of a long chain. The sensor hands raw electrical values to a buffer, the image processor converts and compresses them, and a separate chip called the card controller decides where those bytes physically land inside the flash. The file you see in your computer is the last thing created and the first thing destroyed by a power failure.
That ordering matters. Almost every camera storage failure you will ever encounter — a clip that will not play, a folder that went empty, a card that suddenly reports zero bytes — happens because one link in that chain was interrupted before it finished. Understanding the chain is what turns a meaningless error message into a diagnosis.
What Actually Happens Between the Shutter Press and the Card
The pipeline starts with light and ends with an electrical charge, and the camera treats those two ends very differently.
Step 1: The sensor reads out. A CMOS sensor converts photons into voltages across millions of photodiodes. The readout is not instant — a 45-megapixel full-frame sensor takes tens of milliseconds to shift its rows off the chip. During that window the camera is holding data in volatile memory, and nothing has been written to the card yet.
Step 2: The image processor converts and compresses. A dedicated chip (Canon’s DIGIC, Sony’s BIONZ XR, Nikon’s EXPEED, and so on) applies demosaicing, white balance, noise reduction, and then either JPEG/HEIF compression or a proprietary RAW encoding. This is the most compute-intensive stage, which is why burst shooting fills the buffer before it fills the card.
Step 3: The buffer drains to the card. This is the stage with real risk. The camera writes through a storage interface — UHS-I, UHS-II, or the PCIe lanes behind CFexpress — into the card. The camera is not aware of what happens next, and it has no way to verify that the bytes survived.
Step 4: The card controller maps logical to physical. Every SD, microSD, CFexpress, and SSD-class card contains its own processor and firmware. It receives the camera’s logical block addresses and translates them into physical pages inside the NAND flash. This translation table is maintained by the FTL (Flash Translation Layer).
Step 5: NAND is programmed. The actual storage medium is NAND flash, which can only be written in whole pages and only erased in whole blocks. Reading and writing are asymmetric: a page write takes hundreds of microseconds, a block erase takes milliseconds.
The camera knows about steps 1 through 3. It knows nothing about steps 4 and 5. That asymmetry is the root of nearly every recovery scenario in this knowledge base.
| Pipeline stage | Who performs it | Visible to the camera? | Where failures appear |
|---|---|---|---|
| Sensor readout | CMOS sensor | Yes | Hot pixels, dropped frames |
| Compression and encoding | Image processor | Yes | Truncated JPEG, unplayable video |
| Interface transfer | Camera controller and card interface | Partly | Write errors, “card cannot be used” |
| Logical-to-physical mapping | Card controller (FTL) | No | Card reads as empty or 0 bytes |
| NAND programming | Flash dies | No | Bad blocks, unreadable sectors |
DCIM, File Naming, and the Rules Cameras Follow
Once the bytes reach the card, they need a structure. Almost every digital camera on earth follows the same convention, defined by the CIPA DC-009 standard: a top-level folder called DCIM (Digital Camera IMages), containing subfolders with an eight-character name that begins with a three-digit number and ends in a five-character camera identifier.
A folder named 100CANON or 101MSDCF tells you everything:
- The first three digits are a rolling counter. When a folder reaches its file limit (typically 999 files under most camera implementations, sometimes 9,999), the camera creates
101CANON, then102CANON. - The trailing characters identify the manufacturer.
MSDCFandMSCDFare Sony,CANONis Canon,NIKONis Nikon,FUJIis Fujifilm,GPFRandGOPRare GoPro. - File names follow a four-character prefix plus a four-digit sequence:
IMG_1234.JPG,DSC_1234.NEF,MVI_1234.MP4,GX01 1234.MP4,C0001.MP4.
Two details in that scheme matter enormously for recovery.
First, the four-digit sequence is not a per-card counter — it is a per-folder counter that rolls over at 9999. When it does, the camera increments the folder and starts again at 0001. Two different folders on the same card can therefore contain a file with the same name, which is why organized importers preserve the folder name alongside the file name.
Second, the DCIM structure is a convention, not a filesystem requirement. The card’s filesystem has no idea that DCIM is special. It is a directory like any other. This means that when a card’s directory structures are damaged, the DCIM folder can vanish from the directory listing while the actual photo data sits untouched on the flash — a scenario the why deleted files can be recovered page explains in detail.
Why Cameras Format Cards as FAT32 or exFAT
A camera does not choose a filesystem out of laziness. It chooses one that every host operating system can read without drivers, which in practice means the FAT family.
| Filesystem | Typical camera use | Max file size | Max volume | Practical consequence |
|---|---|---|---|---|
| FAT16 | Very old cameras, cards under 2 GB | 2 GB | 2 GB (at 32 KB clusters) | Cannot hold a modern video clip |
| FAT32 | Cards up to 32 GB, many 64 GB cards | 4 GB | 2 TB (2 TB theoretical, rarely implemented) | Long clips must be split into 4 GB chapters |
| exFAT | Cards 64 GB and larger, most 4K cameras | 16 EB (no practical limit) | 128 PB (no practical limit) | Continuous recording without chapter splitting |
The 4 GB ceiling on FAT32 is the reason chaptered recording exists. A GoPro Hero or a DJI drone recording a 40-minute take does not produce one file; it produces GX01 0001.MP4, GX01 0002.MP4, and so on, each just under 4 GB. Every one of those chapters carries its own header and index, and each one is an independent point of failure.
exFAT removes the 4 GB limit but introduces its own trade-offs. It uses a single File Allocation Table rather than FAT32’s two mirrored copies, so there is less redundancy if the table itself is damaged. It also uses bitmap-based allocation for free clusters, and a corrupted bitmap can make an entire volume report as full or as empty. The what file system do cameras use breakdown covers the brand-by-brand differences, which are more significant than most photographers expect.
Where this gets counter-intuitive: photographers often assume that formatting a card in the camera performs a secure erase. It does not. With very few exceptions, both in-camera formatting and computer formatting are quick operations — the camera writes a fresh boot sector, a fresh File Allocation Table, and an empty root directory, then declares the volume ready. The photo and video data underneath is never touched. It simply becomes unreachable because nothing points at it anymore. That is precisely why a formatted card is usually recoverable, and it is also why the recovery window closes the moment the camera starts recording new files into those same clusters.
The distinction between the two formatting paths is not cosmetic either, and the in-camera format vs computer format comparison is worth reading before you reach for either one.
The Write Is Not Atomic, and That Is the Whole Problem
In database terms, an atomic operation either completes fully or leaves no trace. Camera file writes are not atomic. They happen in a specific, vulnerable order.
For a still photo, the camera typically does this:
- Allocate cluster space in the FAT.
- Write the image data into those clusters.
- Write a directory entry that names the file, records its size, and points to its first cluster.
- Flush the FAT copies.
Steps 1 through 3 each involve a separate write to the card. If power is cut between step 2 and step 3, the image data exists on the flash but no directory entry points to it. The file is not deleted — it was never born. From the user’s perspective the shot is missing; from the flash’s perspective the bytes are all there and fully intact. This is the single most recoverable failure mode in digital photography, and it is invisible to every file browser.
For video, the problem is worse. Container formats such as MP4 and MOV keep their critical index — the moov atom in QuickTime-derived containers — at the end of the file. The camera writes video frames sequentially for the entire take, then patches in the index during a controlled stop. Pull the battery, drop the drone, or let the camera hit its thermal limit mid-recording, and you get a file with every frame present and no index. Players cannot seek through it, so they refuse to open it. It is not corrupted in any meaningful sense; it is unfinished.
There are two further wrinkles worth knowing.
The first is that the card controller may be writing somewhere completely different from where the camera thinks it is writing. Because of wear leveling, the FTL constantly relocates data to spread program/erase cycles across the entire die. A logical address the camera has written a thousand times may map to a different physical page each time. This is good for card longevity and bad for any recovery attempt that assumes physical layout mirrors logical layout.
The second is that the camera’s own buffer can lie. A camera will often report a successful write to the card while the card controller has only accepted the data into its own volatile cache. If power is lost in that window, the block is lost even though the camera said the write completed. This is why “the camera said it saved” and “the file is on the card” are not the same statement.
Why Camera Filesystems Are Structurally Fragile
Putting the pieces together, a camera’s storage stack is fragile for reasons that are architectural, not accidental.
Cards have no TRIM. Solid-state drives in computers and phones issue a TRIM command when files are deleted, telling the controller which blocks are free so it can erase them in the background. Memory cards almost never implement TRIM. Deleted data therefore sits on the flash indefinitely until something overwrites it — which is excellent news for recovery and terrible news for anyone who believes a deleted file is truly gone.
There is no journaling. Filesystems like NTFS and APFS keep a journal of pending metadata changes and can roll back a partially completed operation after a crash. FAT32 and exFAT have no such mechanism. A torn write to the File Allocation Table stays torn.
Metadata is concentrated. A 64 GB card with 8,000 photos may store every one of those photos’ locations in a File Allocation Table occupying only a few megabytes. Damage a handful of sectors in that region and thousands of files become unreachable at once.
Cameras keep writing after a fault. Unlike a computer, which will halt on a write error, many cameras continue firing frames into a struggling card. This multiplies damage: the first error is a symptom, but every subsequent write to a failing card risks overwriting the very data a recovery tool would have found.
Fragmentation is extreme for video. Because video writes are long and sequential but a card is often nearly full, clips end up scattered across the die. A still photo lives in one or two contiguous runs; a 20-minute 4K clip may live in hundreds.
The practical upshot: a card that fails as a filesystem is usually still healthy as a piece of flash. The memory card lifespan article separates genuine hardware wear from the software-level failures that mimic it.
Reading an Error Message with This Model in Mind
Once you know the pipeline, camera errors stop being cryptic. They are reports about which stage failed.
- “Card cannot be used” or “Card error” — the camera mounted the card, read the boot sector, and rejected something in the volume structure. The flash is probably fine; the filesystem metadata is not.
- “Card is write-protected” — the camera cannot write. On an SD card this can be the physical sliding tab, but it can also be a controller that has switched itself to read-only after detecting internal failure.
- “Folder cannot be created” — the camera reached the root directory and its allocation for a new entry failed. This usually means the FAT is inconsistent with the directory, a sign of corruption rather than wear.
- “Unable to display image” — the camera opened the directory entry, followed it to the clusters, and found data that does not decode. The file’s index is missing or its header is damaged.
- “No card in camera” — the card is not completing the initialization handshake at all. This is the one class of error that can indicate physical failure rather than logical corruption.
That mapping is the operating principle behind the camera card error messages reference, which lists more than fifteen real-world messages with the correct first action for each.
What to Do with This Knowledge
Three behaviors follow directly from the storage model described above, and they cost nothing.
Stop writing the instant something looks wrong. Every additional write to a card with lost files consumes free clusters. Since the camera’s allocation strategy is not random, it tends to reuse recently freed regions first — which are exactly where your most recent shoot lives. Power the camera off, remove the card, and do not format it “just to see.”
Record a short test clip on the card before you trust it again. A 10-second clip exercises allocation, sequential write, and index finalization in one action. If the clip plays back in camera and in a card reader, the card’s basic write path is functioning. If it will not play, the card should be retired — not formatted and reused.
Treat a recovered file as unverified until you open it. A successful scan proves that a header was found, not that all the data behind it is present. Open every recovered photo and scrub through every recovered clip before you delete anything.
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.
Following that sequence is the difference between a routine recovery and an unrecoverable one. The how cameras write files article goes deeper on the write ordering described above, and the recover camera data walkthrough applies it step by step.
Frequently Asked Questions
Do cameras really delete files when you press delete?
Only the directory entry. The camera marks the file’s clusters as free in the File Allocation Table and removes its name from the listing, but the image data itself is untouched. Because memory cards do not support TRIM, nothing erases those clusters until new recordings land on them. Deleted photos from a card that has not been reused are fully recoverable.
Why does my camera split long videos into several files?
On FAT32 the maximum file size is 4 GB, so any recording that would exceed it must be split into chapters. Each chapter is a complete, independently indexed file. Cards formatted as exFAT — the default for 64 GB and larger — have no practical size limit, but many action cameras and drones still chapter recordings at fixed intervals for file-safety reasons.
Is a card formatted in the camera different from one formatted in Windows?
In most cases both are quick formats that rewrite the boot sector and File Allocation Table. Cameras additionally create the DCIM folder structure and may use a cluster size better matched to their write pattern. Neither destroys the underlying data. Computer tools that offer a full or low-level format behave differently and should never be used on a card holding files you want back.
Can a camera fail to save a photo even when the review screen shows it?
Yes. The camera previews what is in volatile buffer memory, and a successful-looking review does not guarantee the file was indexed on the card. If power is lost between the data write and the directory entry write, the image is present on the flash but has no name and no location. Recovery tools that scan for file signatures rather than directory entries routinely find these photos.