FAT32 & exFAT: Universal Filesystems

Why FAT Still Matters

In a world of sophisticated journaling filesystems like ext4, XFS, and Btrfs, the FAT family might seem like a relic of the DOS era. Yet FAT is quietly one of the most important filesystems in daily use. Every USB flash drive you have ever plugged into a friend's computer, every SD card in a camera, and every EFI System Partition that boots a modern PC uses some variant of FAT.

The reason is universal compatibility. FAT is the one filesystem that Windows, macOS, Linux, Android, game consoles, cameras, car stereos, and even medical devices all agree on. No other filesystem comes close to this breadth of support. Understanding how FAT works -- and where it falls short -- explains both its enduring relevance and the trade-offs you accept when using it.

The Core Idea: A Linked List of Clusters

At its heart, FAT is elegantly simple. The design revolves around two concepts: clusters and the File Allocation Table itself.

Clusters: The Unit of Storage

A disk is divided into fixed-size blocks called clusters (also called allocation units). A cluster is the smallest amount of space the filesystem can allocate to a file -- typically 4 KB to 64 KB depending on the volume size. Even a 1-byte file occupies one full cluster on disk.

Think of a parking garage where each space fits exactly one car regardless of the car's size. A motorcycle wastes most of its space, while an SUV fits perfectly. This is the fundamental trade-off of cluster size: larger clusters reduce bookkeeping overhead and improve sequential read speed for big files, but waste more space when storing many small files.

The File Allocation Table: A Map of Chains

The File Allocation Table is the data structure that gives the filesystem its name. It is essentially an array with one entry per cluster on the disk. Each entry contains a pointer to the next cluster in a file's chain, forming a linked list.

When you save a file that spans multiple clusters, the filesystem records which cluster comes first (stored in the directory entry), and then each table entry points to the next cluster in the sequence. The final cluster in a chain is marked with a special end-of-chain value.

To read a file, the operating system:

1. Looks up the file's starting cluster number from its directory entry
2. Reads that cluster from disk
3. Consults the FAT to find the next cluster number
4. Repeats until it hits the end-of-chain marker

This is a singly linked list implemented as an array -- one of the simplest possible approaches to tracking file storage.

Anatomy of a FAT Volume

A FAT-formatted volume is divided into four distinct regions laid out sequentially on disk:

Region	Purpose
Boot Sector	Contains volume parameters (cluster size, FAT location, root directory location) and a tiny bootstrap program. This is how the firmware knows how to read the rest of the volume.
File Allocation Table (x2)	Two identical copies of the cluster map. The second copy exists for redundancy -- if the primary table is corrupted, recovery tools can use the backup.
Root Directory	A fixed-size table (on FAT12/FAT16) or a regular cluster chain (on FAT32) listing top-level files and folders. Each entry stores the filename, size, timestamps, attributes, and starting cluster number.
Data Region	The actual clusters where file and subdirectory contents are stored. This is the vast majority of the volume.

The simplicity of this layout is both FAT's greatest strength and its most significant limitation. There is no journal to recover from interrupted writes, no inode table for hard links, no access control lists for permissions, and no B-tree for fast directory lookups.

FAT12, FAT16, FAT32: What the Numbers Mean

The number in each FAT variant refers to the bit width of cluster addresses in the File Allocation Table:

Variant	Cluster Address Width	Max Clusters	Practical Max Volume Size	Era
FAT12	12 bits	4,084	~16 MB	1980 (floppy disks)
FAT16	16 bits	65,524	~2 GB	1987 (early hard drives)
FAT32	28 bits (not 32)	~268 million	~2 TB (with 512-byte sectors)	1996 (large drives)

FAT32's name is slightly misleading: it uses 28 bits for cluster addresses, with the upper 4 bits reserved. Still, 28 bits allow addressing over 268 million clusters, which pushed the practical volume limit to around 2 TB with standard 512-byte sectors.

The Infamous 4 GB File Size Limit

The single most encountered FAT32 limitation is its 4 GB maximum file size. This comes directly from the directory entry format, which stores file size as a 32-bit unsigned integer. The largest value a 32-bit number can hold is 4,294,967,295 bytes -- just under 4 GB.

This was not a concern in 1996 when FAT32 was designed. A large hard drive held 2 GB total. But today, a single video recording from a phone can exceed 4 GB, making this limit a frequent source of frustration when copying files to USB drives.

The workarounds are limited: split the file into smaller pieces, compress it into a multi-part archive, or use a different filesystem. Which leads to the question of exFAT.

exFAT: FAT for the Modern Era

Microsoft introduced exFAT (Extended File Allocation Table) in 2006 specifically to address FAT32's limitations for flash storage. It keeps the conceptual simplicity of FAT while removing the most painful constraints.

What Changed

Aspect	FAT32	exFAT
Maximum file size	4 GB	16 EB (effectively unlimited)
Maximum volume size	2 TB	128 PB (effectively unlimited)
Timestamp resolution	2 seconds	10 milliseconds
Cluster bitmap	Embedded in FAT entries	Separate bitmap for faster allocation
Directory structure	Linear scan	Supports hash-based lookup
Free space tracking	Must scan FAT	Dedicated allocation bitmap

exFAT achieves these improvements by using 64-bit fields for file sizes, introducing a cluster allocation bitmap for fast free-space queries (rather than scanning the entire FAT), and restructuring directory entries to support longer filenames and finer-grained timestamps.

Compatibility

exFAT support is now nearly universal. Windows has supported it since Vista SP1, macOS since 10.6.5, and Linux gained native kernel support in version 5.4 (2019). Android, most cameras, and the SD Card Association's SDXC specification all mandate exFAT. The one area where it falls short is very old or very simple embedded devices that only understand FAT32.

Why FAT Has No Journaling

Modern filesystems like ext4 and NTFS use journaling -- a technique where planned changes are written to a log before being applied. If power is lost mid-write, the journal allows the filesystem to replay or roll back incomplete operations, maintaining consistency.

FAT has no journal. If power is cut while the operating system is updating the File Allocation Table and the directory entry for a file, those two structures can end up inconsistent. The result is orphaned clusters (allocated but not referenced by any file), cross-linked files (two directory entries pointing to the same cluster chain), or lost data.

This is why "safely removing" a USB drive matters far more than many people realize. The operating system buffers writes for performance, and yanking the drive before those buffers flush can corrupt the filesystem. The redundant second copy of the FAT provides some protection, but it is not a substitute for proper journaling.

FAT and Permissions: A Deliberate Absence

FAT was designed for single-user DOS systems and carries no concept of file ownership or Unix-style permissions. Every file is readable and writable by anyone. When Linux mounts a FAT volume, the mount options uid, gid, and umask let you assign synthetic ownership and permission masks, but these are illusions maintained by the kernel -- nothing is stored on disk.

This makes FAT unsuitable for system partitions or multi-user storage, but it is actually an advantage for removable media. A USB drive formatted as FAT works identically regardless of which user or operating system accesses it, because there are no permission bits to conflict.

Choosing the Right Variant

Use FAT32 When:

• Maximum device compatibility is the priority (older car stereos, basic embedded systems, game consoles)
• The drive is 32 GB or smaller
• No single file will exceed 4 GB
• You are formatting an EFI System Partition (the UEFI specification requires FAT32)
• The target device explicitly requires it (many cameras and older devices)

Use exFAT When:

• Files larger than 4 GB need to be stored (video files, disk images, archives)
• The drive is larger than 32 GB
• Cross-platform compatibility is needed between modern systems
• You are using SDXC cards (64 GB and larger SD cards ship formatted as exFAT by default)

Use Neither When:

• The drive will be used exclusively with Linux (ext4 offers journaling, permissions, and better performance)
• Data reliability is critical (use a journaling filesystem)
• You need file permissions, symbolic links, or hard links

Cluster Size: The Hidden Trade-off

Cluster size has a direct impact on both performance and space efficiency, and it is the one decision that deserves thought when formatting a drive.

Cluster Size	Good For	Space Waste on Small Files	Entries in FAT
4 KB	Many small files (documents, code)	Minimal	Large FAT, slower scans
16 KB	Mixed workloads	Moderate	Medium FAT
32 KB	Large files (video, images)	Significant for small files	Small FAT, fast scans
64 KB	Very large files, maximum throughput	Up to 63 KB wasted per small file	Minimal FAT

A 64 KB cluster means that a directory containing 1,000 one-byte files wastes nearly 64 MB of disk space. Conversely, a 4 KB cluster on a 2 TB drive creates a FAT with hundreds of millions of entries, slowing allocation and free-space searches. The formatting tools choose sensible defaults based on volume size, and for most use cases, accepting the default is the right choice.

Cross-Platform Pitfalls

Case Sensitivity

FAT is case-insensitive but case-preserving. It stores README.txt with the capitalization you specify, but treats readme.txt, README.TXT, and Readme.Txt as the same file. This can cause subtle problems when moving files from case-sensitive Linux filesystems: two files that differ only in case will collide on FAT.

Timestamp Behavior

FAT32 stores timestamps in local time with 2-second granularity, while Linux internally uses UTC with nanosecond precision. This means files copied between Linux and Windows can appear to shift by your timezone offset, and files created one second apart may show the same timestamp.

Forbidden Characters

FAT prohibits the characters \ / : * ? " < > | in filenames. Files with these characters (valid on Linux ext4) cannot be copied to a FAT volume without renaming.

The EFI Connection

One reason FAT will persist indefinitely is the UEFI specification. Every UEFI-based computer (which is nearly all computers manufactured since 2012) requires an EFI System Partition formatted as FAT32. This partition holds bootloader binaries, and UEFI firmware contains a built-in FAT32 driver to read them.

This means that even in a future where all data drives use advanced filesystems, the boot process itself will continue to depend on FAT32. It is embedded in the foundation of modern computing.

Key Takeaways

1. FAT's power is its simplicity -- a linked list of clusters tracked by an array. Any device, no matter how limited, can implement a FAT driver.

2. The 4 GB file size limit is a 32-bit artifact -- the directory entry stores size as a 32-bit integer. exFAT removes this constraint with 64-bit fields.

3. No journaling means no crash safety -- always safely eject removable media to avoid filesystem corruption from buffered writes.

4. FAT32 for maximum compatibility, exFAT for large files -- this is the practical decision framework for removable storage.

5. UEFI guarantees FAT's future -- every modern computer boots through a FAT32 partition, ensuring the format will remain relevant for decades to come.

Related Concepts

Back to Filesystems Overview