File Allocation Table (FAT) Overview

Major characteristics

Multiple variations date back to the twentieth century, and are very widely supported. Existing widespread support is likely FAT's most charming quality.

Notably, did not store any details to try to keep track of “permissions” or other security-related details.

Versions supported by MS-DOS and Win9x
Versions supported by MS-DOS
  • FAT12 (possibly maximizing at 16MB, which was plenty when using the popular data storage media known as a “floppy disk” which typically stored 2MB or less).
  • Was actually originally named just “File Allocation Table” (“FAT”), but people have started calling it FAT12 in hindsight (retronym'ed/backronym'ed, similar to how ATA has been renamed to PATA)
(the only option other than FAT-12 or ISO 9660 which was supported by MS-DOS versions up to 6.22, which was once the most popular commercial operating system on the planet). Widely supported by many other operating systems. When using a typical sector size of 512 bytes, this maxed out at 4 GB, although popular Microsoft operating systems could be limited to 2 GB.

Microsoft Windows 95 was the first to support this. Basically, this is a variation of the typical FAT support which allowed the enhancement of “Long Filename” (“LFN”) data to be stored. The LFN data would be stored in addition to the typical data stored on a FAT system, including the short filename. So, files that used a “long filename” would actually have two filenames: both the short filename and also the long filename.

This way, programs that used LFN support would be able to use long filenames. However, programs that did not have LFN support would still be able to interact with the files by using the SFN (“short filename”) data, which would still be used. (In contrast, a rival commercial and partially operating system named OS/2 could store files with long filenames, but those files were often invisible to software that didn't have the “long filename” support.)

The ability to use “long filename” support, compatible with Microsoft Windows 95, was invented by Microsoft (for use in Microsoft Windows 95), but Unix systems (and perhaps specifically Linux-based operating systems) popularized the name “VFAT” (which stands for “virtual FAT”) to refer to the same thing.

Supported some larger capacities.
  • Operating systems typically abandoned relying on FAT-32 due to favoring other filesystem types, not due to a capacity limitation. (For Microsoft Windows, the size-limiting issue was 128 GB (basically 2 raised to the 27th power) caused by an implementation of 28-bit Logical Block Addressing (“LBA”) communication. Windows XP Service Pack 1 remedied this by adding “LBA 48” support, which can support up to 128 petabytes.
  • However, there is a limit of 4 GB per individual file. A typical single-layer DVD supports 4.7 billion bytes, about 4.3 GB, which exceeds that, so many DVD images don't fit into that FAT32 limitation.
  • Used by “Secure Digital High Capacity” (“SDHC”) cards


Designed to support some higher capacities, and a format which Microsoft has more heavily protected with modern laws regarding “intellectual property”.

Sometimes called FAT64.


There was some code released that allowed an operating system, using a Linux kernel, to effectively use a FAT drive. Probably somewhat similar to how Microsoft added LFN support to the old FAT standard, this involved adding support for Unix permissions, and other details common on Ext2 drives, to a FAT drive. (This was done by storing the additional information in files named --LINUX-.--- which people could simply ignore. Those files could be updated using a command named “umssync”.)

Support for UMSDOS has been dropped. UMSDOS FAQ, UMSDOS FAQ section 2.2: History says, “The Umsdos project was started in 1992 and made available to the net in January 1994 as a patch. It was included in the standard kernel distribution in July, starting with kernel 1.1.36.” Since around 1.1.70, the UMS FAQ identifies this as being stable, but the FAT also notes, “A major bug was solve in Linux 1.2.2.”

Linux Kernel v2.6.11 summary of changes (from v2.6.10) “UMSDOS has been non-function since early 2.5 and would need a major rewrite to be resurrected”. AN!Wiki AN!Tools :: Filesystems :: UMSDOS summarizes the demise of UMSDOS as, “Support for this overlay file system was removed from the Linux kernel 2.6.11 due to lack of maintenance.” (A discussion about that has been archived at: Wayback Machine @ Developer mailing list: Removing UMSDOS.)

A related bit of software was ZipSlack. (Wikipedia's article for ZipSlack)

FATX (FATX16 and FATX32)
Not widely supported except that this has been used on Xbox video game systems. The sheer number of Xbox video game systems that have been manufactured is the main reason that seemed compelling enough to include this filesystem in this list.

FAT12 and FAT16 are the most widely supported filesystems on the planet. (FATX, on the other hand, has not been typically supported by a very wide variety of devices, although its usage is a bit widespread since those computing devices have been manufactured in high quantities.)


FAT12 and, with newer versions, FAT16

  • MS-DOS contained a number of commands that worked with FAT filesystem volumes:
    volume checking
    checkdsk checks volumes (Windows XP and newer did use chkdsk instead), ScanDisk was introduced by MS-DOS 6 (and may be more reliable with MS-DOS 6.2 and newer)
    volume creation
    FORMAT creates a volume
    volume label modification
    LABEL displays and changes volume labels
    file attributes
    fragmentation handling
    MS-DOS 6 introduced Defrag
    data loss recovery
    Undelete worked about as well as could be expected, except that it did typically lose track of the first character of the deleted file's name
    • FDISK modifies partitions using the “master boot record” (“MBR”) partitioning scheme.
    • Some commands, Mirror and Unformat, may not have been as useful as people thought. They may have been only useful in specific scenarios, and contained bugs. Specific details would vary based on which version of an operating system was being used.
  • Some of the above commands are widely supported by operating systems that provide DOS compatibility (e.g., Label, Format), while others are a bit more specific to certain versions. ScanDisk and Defrag were licensed by Norton, who made a software package (Norton Disk Utilities?).
  • Other DOS versions had software with some similar capabilities, such as DiskOpt which could optimize a disk's structures by defragmenting the disk, and Unerase.
Microsoft Windows
  • Windows 95 supports FAT12, FAT16, and VFAT.
  • Windows 95 OSR2, Windows 98, and newer also support FAT32.
  • Windows XP update KB955704 and Windows Vista SP1 and newer also support exFAT. (As an exception to that, Vista's ReadyBoost feature does not work with exFAT. Windows 7 can use ReadyBoost with exFAT.)
  • Windows Server 2008 supports exFAT, except Windows Server 2008 R2 using Windows Server 2008 Server Core.
  • Many of the commands supported by Microsoft Windows 95 and newer match those of MS-DOS releases that came earlier.
  • Windows 98 and Windows ME contained a graphical “Scan Disk” program, which could be started using the executable file named “Scandskw.exe”. Microsoft has since removed that.
    • You may manually mark a drive as having a dirty bit using “ FSUtil dirty set C: ”.
  • At some point (by Windows 10, likely earlier), “Defragment and Optimize Drives” became named %windir%\system32\dfrgui.exe
Max OS X Snow Leopard 10.6.5 supports exFAT.

OpenBSD supports at least some versions of FAT using a name of “msdos”. e.g., “ mount -t msdos ”, “ mount_msdos ”, “ fsck -t msdos ”, “ fsck_msdos ”, “ newfs -t msdos ”, “ newfs_msdos

The ability to modify the “label” of a FAT volume (similar to the “ LABEL ” command in MS-DOS) may be supported by a command called “ fatlabel ” (from a package named “dosfstools”). There is also an “mtools” package. (Maybe the “mtools” package contains a program named “ dosfslabel ”?)


Many Linux systemsthis using a name of “vfat”. e.g., “ mount -t vfat ”, “ fsck -t msdos ”, “ fsck_vfat ” (and “ fsck_msdos ”, both of which may simply be hyperlinks to “ dosfsck ”), “ mkfs -t vfat ”, “ mkfs.vfat ” (and “ mkfs.msdos ”, both of which may simply be hyperlinks to “ mkdosfs ”). The ability to modify the “label” of a FAT volume (similar to the “ LABEL ” command in MS-DOS) may be supported by a command called “ dosfslabel ” (from the “mtools” package?) and/or “ fatlabel ” (from a package named “dosfstools”).

Support may be provided by a package named dosfstools

A software package named “mtools” may supply some ability to interact with a volume, without using standard capabilities like mounting the volume. This may primarily be useful for operating systems that don't have a nice version of dosfstools.

Linux-based operating systems used to be able to be installed to a FAT drive, using UMSDOS. Modern Linux kernels have dropped compatibility with UMSDOS.

Regarding exFAT, the situation seems to be a bit murkier (at the time of this writing). See: LinuxPro Magazine November 2013 Article: Understanding exFAT issues (Freedom of Choice), LinuxPro Magazine article from August 2009, “Tuxera Closes ExFAT Patent Agreement with Microsoft”

SD cards

SD cards could come formatted with any format, or be unformatted. SDHC cards come pre-formmated using FAT32. SDXC cards use exFAT.