exFAT (Extensible File Allocation Table)

Microsoft introduced exFAT in 2006 with Windows CE 6.0, designed specifically to fix two FAT32 problems for the flash-storage era: the 4 GB file size limit and the 2 TB volume limit. The name says everything about the design philosophy: Extensible File Allocation Table, an evolution of the FAT family that keeps the simplicity (a few kilobytes of code, easy to implement on embedded devices) while removing the size constraints. The SD Association adopted exFAT as the required file system for SDXC cards (64 GB and larger) in 2009, which is why every SDXC card you buy ships exFAT-formatted.¹

For 13 years, exFAT was proprietary and patent-encumbered, which is why open-source operating systems like Linux had to rely on third-party drivers. Microsoft published the spec and released the patents to the Open Invention Network in 2019, which opened the way for native Linux kernel support starting with kernel 5.4 in late 2019. By 2026, exFAT support is universal across Windows, macOS, Linux, and most modern consumer devices.²

The four regions of an exFAT volume

An exFAT volume has a structured layout that’s been stable since the 2006 spec:³

1. Main Boot Region. Sectors 0 through 11. Contains the boot sector with file system parameters (sectors per cluster, FAT location, cluster heap location, root directory cluster), boot code, and OEM-specific parameters. Sector 0 starts with the signature “EXFAT” plus three trailing spaces, which is how the OS identifies the volume as exFAT rather than FAT32 or NTFS (all three use partition type 0x07).
2. Backup Boot Region. Sectors 12 through 23. An exact copy of the Main Boot Region. If the main boot sector becomes corrupted, recovery tools restore it from the backup. This is exFAT’s primary recovery resource; the same redundancy approach FAT32 uses but extended to all 12 boot-region sectors.
3. FAT Region. Holds one File Allocation Table (or two with TexFAT) describing cluster chains for fragmented files. Critically, exFAT’s FAT works differently from FAT32’s: it is not the source of truth for cluster allocation, only for chain linkage on fragmented files. Most files don’t even use the FAT.
4. Cluster Heap. The bulk of the volume. Contains the Allocation Bitmap, the Up-Case Table, the Root Directory, and all file data. Files and folders are stored as series of clusters here.

The Allocation Bitmap: not a FAT

The most fundamental architectural shift from FAT32 to exFAT is how cluster allocation status is tracked. FAT32 used the FAT itself to indicate whether each cluster is free or in use (cluster value of 0x00000000 means free). exFAT replaces this with a dedicated Allocation Bitmap: a sequence of bits, one per cluster, where 1 means in-use and 0 means free.⁴

The benefits are significant:

• Faster free-space queries. Counting free clusters means counting zero bits in the bitmap, much faster than walking the entire FAT.
• Less disk I/O on writes. Allocating a new cluster means flipping one bit in the bitmap, not writing a 4-byte FAT entry.
• Simpler defragmentation. The bitmap and the FAT (when present) can be inspected independently.

The trade-off: when both the Allocation Bitmap and the FAT become corrupted, recovery is harder than on FAT32 because the redundancy that FAT32’s two FAT copies provided is gone. exFAT relies on the Backup Boot Region for boot-level recovery, but cluster-allocation recovery requires file system reconstruction from directory entries.

The NoFatChain optimization

This is exFAT’s clever trick that consumer-facing pages skip but matters significantly for understanding how the file system works in practice. Each file’s directory entry has a NoFatChain flag. When this flag is set:⁵

• The file’s clusters are guaranteed to be contiguous on disk (cluster N, N+1, N+2, …).
• The OS reads only the starting cluster and the file size to find all the data; the FAT is not consulted.
• Writing the file does not update the FAT; only the bitmap is changed.

When the file is fragmented, the NoFatChain flag is cleared and the FAT chain is used like FAT32. For typical exFAT use cases (large media files written sequentially to flash storage), most files end up with NoFatChain set and the FAT region is barely used. This is why exFAT is fast on flash: it does dramatically fewer FAT writes than FAT32 would.

Directory entry sets

Each file or folder on exFAT is described by a directory entry set of 3 to 19 separate 32-byte entries:⁶

• File Directory Entry (1 entry). Holds attributes, timestamps, and a checksum of the entire entry set. Type 0x85.
• Stream Extension Entry (1 entry). Holds the file size, the first cluster number, and the NoFatChain flag. Type 0xC0.
• File Name Entries (1 to 17 entries). Each holds 15 Unicode characters of the filename. Long filenames span multiple entries. Type 0xC1.

Filenames can be up to 255 Unicode characters. Each entry has an InUse bit in its type byte; deletion clears these InUse bits across the entire set without changing the filename or other data, which is similar to FAT32’s 0xE5 marker but cleaner. The filename, file size, and starting cluster all stay intact in the deleted entry, which makes undelete recovery practical.

NameHash for fast filename comparison

Each Stream Extension Entry includes a NameHash field, a small hash computed from the up-cased filename. When the OS looks up a file by name, it computes the hash of the requested name and compares against the NameHash field before doing a full filename comparison. This is similar to NTFS’s hash optimization but cheaper (16-bit hash vs full B-tree). Recovery tools use NameHash to verify whether a recovered filename is still valid, since a hash mismatch means the entry has been corrupted.

exFAT was designed with three goals: support large files and volumes, work well on flash storage, and stay simple enough to implement on embedded systems. Every feature traces back to one of these.⁷

Size limits removed

• Maximum file size: 16 EB minus 1 byte (theoretical), bounded in practice by the volume size. For consumer use, the file size limit is effectively unlimited.
• Maximum volume size: 128 PB by spec, with 512 TB recommended maximum. No consumer storage in 2026 approaches these numbers.
• Maximum cluster size: 32 MB, much larger than FAT32’s 32 KB max. Larger clusters reduce metadata overhead on huge volumes but waste space for small files.
• Maximum files per directory: 2,796,202 file sets in a 256 MB subdirectory, dramatically more than FAT32’s effective limit.
• Maximum filename length: 255 Unicode characters, same as NTFS.

Flash-friendly design

exFAT was designed with NAND flash characteristics in mind:

• Boundary alignment. The FAT and cluster heap can be aligned to flash erase block boundaries (typically 128 KB or 256 KB) to minimize the number of flash blocks affected by writes.
• NoFatChain optimization. Most flash storage writes are sequential, contiguous, and large; exFAT’s NoFatChain pattern means these writes don’t update the FAT at all, reducing wear on the FAT region.
• No journaling. Sounds like a downside, but it means fewer writes overall, which extends flash media lifespan.
• TRIM support. Modern exFAT implementations issue TRIM commands when files are deleted, letting the flash controller reclaim cells.

Where exFAT is the standard

exFAT is the default or required file system in several specific scenarios:

• SDXC cards (64 GB and larger). Required by the SD Association spec. Reformatting to FAT32 or NTFS is generally a mistake; the card may stop working in some SD card compatible devices.
• microSDXC cards. Same as full-size SDXC. The Switch, modern Android phones, drones, and dashcams all expect exFAT.
• Cross-platform external drives. The standard choice for external hard drives shared between Windows and macOS.
• USB flash drives over 32 GB. The default Windows format choice when FAT32 isn’t selected.
• Modern game console storage. Switch, PS5, Xbox Series accept exFAT for game storage and screenshots.
• Modern car infotainment. Most car head units from 2018 onward accept exFAT in addition to FAT32.
• Action cameras and drones. GoPro, DJI, and others default to exFAT on cards over 32 GB.

exFAT sits between FAT32 (older, more compatible, file size limits) and NTFS (more features, less portable). The right choice depends on what devices need to read the drive and what files you’re storing.⁸

Property	exFAT	FAT32	NTFS
Year introduced	2006	1996	1993
Max file size	16 EB theoretical	4 GB minus 1 byte	8 PB practical
Max volume size	128 PB	2 TB	256 TB practical
Journaling	No	No	Yes
Permissions / ACLs	No	No	Yes
Encryption	BitLocker only	No	EFS + BitLocker
Compression	No	No	Yes
Windows support	Win 7+ native	All versions	All modern
macOS support	Read+write native	Read+write	Read-only natively
Linux support	Native (kernel 5.4+)	Read+write	Read+write (NTFS3)
SDXC default by spec	Yes	No	No
Old game consoles (PS3, Xbox 360)	No	Yes	No
Modern consoles (PS5, Switch)	Yes	Yes	No
Recovery difficulty	Medium	Easiest	Medium
Best for	Cross-platform >4 GB	Universal compatibility	Internal Windows drives

When to use each

Use exFAT for: SDXC cards (always, never reformat); cross-platform external drives shared between Windows and macOS; USB flash drives over 32 GB that may hold files larger than 4 GB; SD cards in modern cameras, drones, and dashcams; Switch / PS5 game storage. exFAT is the right answer for most modern consumer flash storage scenarios.

Use FAT32 for: small flash drives that need to work with old devices (PS3, original Xbox 360, pre-2018 car stereos, basic cameras); UEFI boot partitions; embedded systems; SD cards under 32 GB used in old equipment. FAT32’s 4 GB limit rarely matters for these use cases, and its universal compatibility is unmatched.

Use NTFS for: any internal drive on a Windows system; external drives used exclusively with Windows; drives where journaling protection against crash corruption matters more than cross-platform support. NTFS’s feature set is overkill for removable flash storage and its weaker macOS support is a significant drawback for cross-platform use.

exFAT’s corruption modes overlap with FAT32’s because both lack journaling. The distinct difference: exFAT uses the Allocation Bitmap as the source of truth for cluster allocation, so bitmap corruption is a new failure mode that doesn’t exist on FAT32. Most exFAT problems trace back to improper ejection during writes or sudden power loss.⁹

• Main Boot Region damage. The 12-sector boot region at the start of the volume is overwritten or corrupted. Symptoms: drive shows as RAW, Windows asks to format, or shows an unrecognized file system. The Backup Boot Region (sectors 12-23) is an exact copy and can be used to restore the main region. TestDisk, R-Studio, and similar tools handle this automatically.
• Allocation Bitmap corruption. The bitmap that tracks which clusters are in use becomes inconsistent with reality. Symptoms: free space reported incorrectly, files claiming overlapping clusters, or the OS refusing to write new files despite available space. Recovery tools rebuild the bitmap by walking all directory entries and marking referenced clusters as in-use.
• FAT corruption (fragmented files only). Cluster chains for fragmented files become damaged. Files with the NoFatChain flag set are unaffected because their clusters are contiguous and the FAT isn’t consulted. Recovery for fragmented files requires reconstructing chains from surrounding context or accepting partial file recovery.
• Directory entry set damage. One or more entries in a file’s 3-19 entry set become corrupted. The File entry has a checksum field that lets the OS detect tampering across the whole set; mismatched checksums trigger the OS to mark the file as invalid. Recovery software bypasses the checksum and reconstructs the file from the remaining valid entries.
• NoFatChain inconsistency. A file marked as NoFatChain (contiguous) actually spans non-contiguous clusters because of incomplete writes or improper recovery from a previous corruption. The OS reads garbage past the first contiguous run. Recovery tools detect this by comparing file content against expected file signatures.
• RAW partition state. The OS sees the drive but reports no recognizable file system, often after sudden disconnection during a write. The boot region is usually fine; the issue is that the OS can’t find the FAT or cluster heap pointers properly. Recovery tools find the boot region from the backup and rebuild the volume.
• Bad sectors in critical regions. Physical bad sectors on the underlying disk hit the Allocation Bitmap, the FAT, or the root directory. Catastrophic for that file system structure but the data area is usually fine. Imaging the volume with ddrescue (which marks unreadable sectors but continues) gives recovery software something to work with.
• Accidental quick format. A “Quick Format” wipes the boot region’s pointers and writes a fresh empty Allocation Bitmap, but doesn’t touch the data area or the directory entry sets. Recovery is straightforward: the entries still exist with their cluster pointers intact; recovery software reads them and reconstructs files from the cluster heap.

Warning signs your exFAT volume is failing

Like FAT32, exFAT itself doesn’t usually warn about its own internal state; warnings come from the underlying hardware or from OS-level error messages. Watch for these in combination:

• “You need to format the disk before you can use it” prompts on a drive that worked yesterday. Almost always boot region or directory damage from improper ejection. Click Cancel.
• “The file or directory is corrupted and unreadable” errors on specific files. Directory entry set corruption for that file; the rest of the volume is usually fine.
• Files appearing as 0 bytes or with incorrect sizes. Stream Extension Entry damage; recovery software can rebuild from the cluster data.
• Free space reported incorrectly. Allocation Bitmap inconsistency. Running chkdsk on Windows usually rebuilds the bitmap, but only run it after imaging the drive first.
• Filenames showing as garbage characters. File Name entries have been corrupted. The file’s data is likely still intact; recovery software finds files by content and assigns generic names.
• Drive disconnects during transfers. Often a USB cable issue or a marginal flash controller. Try different cables and ports first.
• Slow file copies that progressively get slower. Often indicates accumulated bad sectors on the underlying media being retried by the OS. Stop using the drive and image it.

FAT32 was the universal file system for removable flash storage from 1996 through roughly 2010. Then exFAT took over for any drive larger than 32 GB and any device that needed files over 4 GB. The transition wasn’t an arbitrary marketing decision; the technical reasons were specific and the SD Association making exFAT mandatory for SDXC was the inflection point.¹⁰

Three forces drove the transition

The 4 GB file ceiling became impractical. By the mid-2000s, HD video files routinely exceeded 4 GB, and 4K video in the 2010s pushed average file sizes to 10-50 GB. FAT32 simply couldn’t store these files; users hit “the file is too large for the destination file system” constantly when copying video to USB drives.

SDXC cards needed it. When the SD Association introduced SDXC in 2009 (capacities from 32 GB to 2 TB), they made exFAT mandatory. Every SDXC card from every manufacturer ships exFAT-formatted from the factory. The huge consumer market for SDXC cards in cameras, phones, and Switches made exFAT support a hardware requirement on every device that wanted to read those cards.

The 2019 OIN release opened up Linux and open-source. Before 2019, exFAT support on Linux required third-party drivers (FUSE-based exfat-fuse, or proprietary drivers from Samsung). Microsoft’s release of the spec and patents to the Open Invention Network led to native kernel support in Linux 5.4. By 2026, exFAT works the same way on Windows, macOS, and Linux without driver concerns.²

exFAT advantages and drawbacks