Cameras almost never ask which file system you want, and that omission causes a large share of card confusion. The short answer to what file system do cameras use: FAT32 on cards up to 32 GB, exFAT on anything larger, and neither NTFS nor APFS. Format a camera card on a computer without checking the dropdown, and you can build a volume the camera cannot read.
The warning follows immediately. When a camera rejects a card it usually offers to format it, and accepting that prompt is how a five-second incompatibility becomes a data loss case.
FAT32: The 32 GB Wall That Still Rejects New Cards
FAT32 is a 1996 design with an arithmetic limit. It addresses storage with 32-bit cluster numbers, capping a volume at 4,294,967,296 clusters, and each directory entry’s file size field is also 32-bit. The SD Association drew its capacity classes along the same lines: SDHC spans 2 GB to 32 GB and specifies FAT32, while SDXC begins at 64 GB and specifies exFAT. Microsoft’s formatting tools have declined to create FAT32 volumes above 32 GB for decades, and camera firmware inherited that assumption.
The symptom looks like a hardware fault and is not. Insert a 128 GB exFAT card into a body built for SDHC and it reports a card error, reports no card, or offers to format. The firmware contains a FAT32 driver, and that driver has no code path for an exFAT boot sector, an allocation bitmap, or 32-byte entry sets.
The trap is what happens next. Some older bodies, asked to format a card beyond their supported volume size, create a FAT32 partition of roughly 32 GB and leave the rest unallocated. The camera then works perfectly, on a third of the capacity you paid for, with no warning. Buy cards in the size class the body documents, and check reported capacity in the camera menu after any format. The classes themselves are compared in the guide to camera memory card types.
The 4 GB Ceiling and Why Long Recordings Arrive in Pieces
FAT32 caps a single file at 4,294,967,295 bytes — 4 GB minus one byte — because the size field cannot hold a larger number. A recording that runs longer cannot be written as one file, so the camera closes the current file and opens the next. This is the origin of the numbered file sets that action cameras and camcorders produce, including GoPro chapters such as GX010042.MP4.
The first consequence is diagnostic. A folder of several numbered clips of similar size, all from one continuous take, is not a folder of damaged files. It is one recording divided by the file system, and the job is to join the pieces in the right order. The sequence lives in the naming convention, not the timestamps. How GoPro chaptering works decodes the numbering, and if the pieces are already separated, reassembling chaptered video covers the join.
The second is counterintuitive: on a FAT32 card, forced chaptering improves your odds after a failure. Each file is closed and indexed before the next begins, so an interrupted recording costs you the final chapter and nothing else. On an exFAT card recording the same session as one file, the same interruption can leave a single enormous file with no index at all — the chapter boundary you dislike at import time is a checkpoint you did not ask for.
exFAT: What Actually Changed at 64 GB
exFAT arrived in 2006 and became the required format for SDXC media. It replaces the 32-bit allocation table with a 64-bit structure, raising the volume ceiling to 128 petabytes and the maximum file size to 16 exabytes. For cameras, two effects matter: any consumer card size works without partitioning, and the 4 GB per-file limit disappears.
The trade is real, and it is the most important fact here for anyone who may need to recover data. FAT32 keeps two copies of its File Allocation Table; exFAT keeps one allocation bitmap. A damaged primary table on a FAT32 card can often be rebuilt from the second copy, while a damaged exFAT bitmap is simply damaged. exFAT also stores its directory as a cluster chain rather than at a fixed location, and groups directory data into entry sets whose checksum must match, so a partly written entry set is unusable rather than degraded.
Neither file system journals. NTFS and APFS log pending metadata changes and can roll an incomplete transaction back after a crash. FAT32 and exFAT have no log, so an interrupted metadata write is an incomplete write with nothing to recover it from. That is the structural reason cards corrupt more readily than computer drives built on identical flash, and the ordering behind it is described in how cameras write files.
The macOS Trap: APFS and a Camera That Cannot Read Its Own Card
Disk Utility on a current Mac defaults to APFS; older versions defaulted to Mac OS Extended. Every consumer camera is blind to both, and choosing either is the most common way a working card becomes a card the body will not mount.
The failure is easy to read once you know the shapes. The card mounts on the Mac and looks healthy; the camera then shows a format prompt, a card error, or no card. Since the camera offers the only fix it knows, users often accept the reformat before asking what was on it.
What that reformat destroyed is worth stating precisely. Writing an APFS container does not overwrite video data the way a secure erase would. It writes new volume structures at specific locations and marks the rest available. The old exFAT boot sector, bitmap, and directory chain are gone where APFS wrote, but the media files usually survive in the data region. That is why a Mac-formatted card is a recovery candidate rather than a write-off.
The second Mac problem is quieter. macOS writes bookkeeping to any writable volume it mounts: .Spotlight-V100 and .fseventsd for indexing, .DS_Store when you browse a folder, sometimes a repair pass after an unclean removal. None of it touches footage directly, but each is a write to a card that was meant to stay inert. Mount such a card read-only, or use the physical write-protect tab.
On Windows the equivalent mistake is NTFS, which cameras also cannot read and which carries a journal camera firmware has no code to interpret. When a computer-side format is unavoidable, choose exFAT with the default allocation unit size and a quick format rather than a full one. The difference between those two options is set out in in-camera versus computer formatting.
A Compatibility Table for Cards, Cameras, and Computers
| File system | Where you meet it | Practical volume ceiling | Maximum single file | Camera can read it | Recovery friendliness |
|---|---|---|---|---|---|
| FAT16 | SD cards of 2 GB and below | 2 GB | 2 GB | Yes, on older bodies | Moderate: tiny tables, fixed directory, 8.3 name limits |
| FAT32 | SDHC 4–32 GB, older internal media | 32 GB in practice | 4 GB minus 1 byte | Yes | Very good: duplicate allocation table, fixed root directory |
| exFAT | SDXC 64 GB and up, CFexpress, XQD | Effectively unlimited for cards | 16 EB | Yes, on current bodies | Good: one allocation bitmap, no fallback copy |
| NTFS | Windows default for fixed drives | 256 TB and beyond | 16 TB | No | Irrelevant for cards, and its journal is unreadable to cameras |
| APFS | macOS default for internal and external SSDs | 8 EB | 8 EB | No | Poor as a card format: the original FAT structures are gone |
Read the fourth column first: on a shoot day the only question that stops work is whether the camera will mount the card, and that depends entirely on whether the volume is FAT32 or exFAT. Note the inversion: the format easiest to create on a modern laptop is the one that strips out the structures recovery software reads.
How Each File System Behaves After Corruption
Recoverability is a property of structure, not of the software installed afterward.
FAT32 fails partially and recoverably. Two allocation table copies, a fixed root directory, and fixed 32-byte directory entries give a recovery tool a great deal to work with. If one table copy is unreadable the other can be parsed; if both are unusable, the directory entries still hold names, sizes, timestamps, and starting clusters, which is enough to rebuild a file by following its chain. A FAT32 card that refuses to mount therefore often returns a near-complete listing after a scan.
exFAT fails more abruptly. The allocation bitmap is a single point of failure and the directory is a linked structure rather than a table. When the core structures are damaged the card often will not mount at all, so instead of a degraded listing you get nothing. The data region is untouched, so a raw scan still finds files by signature, but names, folders, and timestamps are gone because they lived in the entry sets the damage destroyed.
APFS on a camera card is a different problem entirely. No camera writes APFS, so a card in that state was formatted by a computer, and the original FAT32 or exFAT structures no longer exist where APFS wrote over them. With no directory to reconstruct and no allocation table to follow, recovery becomes signature carving: find JPEG, MP4, and RAW headers in the data region and extract what follows. That works well for photographs, which carry clear start and end markers, and poorly for long video, which depends on an index that lived in the destroyed directory.
One pattern surprises people repeatedly. A card that will not mount is usually the better case; a card that mounts and shows fewer files than expected is often the worse one. The first is a metadata failure with intact data behind it. The second usually means files were lost and their space has since been reused, which is covered in why deleted photos can be recovered.
When a file system is damaged, the first move never varies: stop writing, pull the card from the camera, and decline any format prompt. From there, the corrupted SD card recovery workflow covers a card that mounts but reads badly, while the card not detected decision tree separates a broken reader, a broken card, and a volume the host cannot parse.
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. The file system decides how much structure survives to guide that scan; it does not change whether overwritten data can return.
Frequently Asked Questions
Can I use an exFAT card in an older camera that only supports FAT32?
Not directly. A body built for SDHC contains a FAT32 driver and cannot parse an exFAT boot sector, so it reports a card error or offers to format. There is no workaround that keeps both capacity and compatibility: format the card as FAT32 and accept the 32 GB ceiling, or use a card in the size class the camera documents.
Why does my camera split long videos into several files?
Because of the 4 GB per-file limit on a FAT32 card, or by design on an exFAT card. Either way the pieces form one continuous recording. Do not treat them as damaged; join them in the order the file names encode, which reflects the sequence rather than the modification timestamp.
Will a camera read a card formatted as APFS on macOS?
No camera will, because APFS is a macOS format that no camera firmware implements. The body reports an error or asks to format. The underlying photos and videos usually survive until new data overwrites them, since the APFS container writes new structures rather than erasing the whole card.
Which file system recovers best after corruption?
FAT32, for structural reasons rather than age. It keeps two copies of its allocation table, a fixed root directory, and fixed-size directory entries, all of which help a tool rebuild a file. exFAT holds the same data region but only one allocation bitmap, so its metadata failures tend to be all or nothing.