How to Format an External SSD for Mac: I Tested 10 Formats

Disk Utility gives you a dropdown and then erases your drive. On the Mac mini that publishes this blog — macOS 26.4.1, build 25E253 — diskutil listFilesystems prints twelve formattable personalities, and the menu tells you nothing about what you just traded away. Every guide I read answers the question the same way: APFS if the drive is Mac-only, exFAT if you also use Windows. None of them puts a number on what exFAT costs you.

So I built a scratch volume in ten of those formats and ran an identical battery of tests against each one. The most expensive difference is the one nobody mentions: on a drive of any realistic size, exFAT charges 128 KiB to store a one-byte file. APFS charges 4 KiB.

What I measured, and what I couldn't

I have no physical external drive. That is not a rhetorical setup — diskutil list external returns empty output on this machine and system_profiler SPUSBDataType shows zero USB storage devices, which is the same empty inventory behind the recoverability audit I published this morning. So I made the volumes with hdiutil create -type SPARSE -fs <personality>, attached them, and tested the file system layer.

That method is valid for what I claim and invalid for what I don't. Allocation block size, timestamp resolution, sparse-file support, permission handling and file-size ceilings belong to the file system, not to the plastic it sits on. Throughput and thermals belong to the backing store, so I did not measure them — read no speed claim into this piece.

My first run was wrong — in exactly the direction the internet is wrong

The first pass recorded exFAT: >4 GiB single file = no — a claim you can find repeated across search results, and I nearly published it. It was an artifact: the preceding sparse-file test had already allocated a real 1 GiB on a 6 GB volume, so a 5 GiB file had nowhere to go.

Re-running each test on an empty 16 GB volume changed the answer. exFAT wrote the 5 GiB file without complaint. FAT32, FAT16 and FAT12 all failed identically with dd: truncating big: File too large. The 4 GiB wall belongs to FAT, not to exFAT — and the reason so much advice conflates them is that they get tested the way I tested them the first time.

The matrix

Personality	diskutil list TYPE	Case	chmod 600 → mode	Hard links	>4 GiB file	1 GiB hole costs	mtime kept
APFS	APFS	insensitive	600	yes	yes	4 KiB	nanosecond
APFS (Case-sensitive)	APFS	sensitive	600	yes	yes	4 KiB	nanosecond
Mac OS Extended (Journaled)	Apple_HFS	insensitive	600	yes	yes	1 GiB	1 second
Mac OS Extended (CS, Journaled)	Apple_HFS	sensitive	600	yes	yes	1 GiB	1 second
ExFAT	Windows_NTFS	insensitive	700	no	yes	1 GiB	10 ms
MS-DOS (FAT32)	DOS_FAT_32	insensitive	700	no	no	1 GiB	2 seconds
MS-DOS (FAT16)	DOS_FAT_16	insensitive	700	no	no	unsupported	2 seconds
MS-DOS (FAT12)	DOS_FAT_12	insensitive	700	no	no	unsupported	2 seconds

Two entries in that table are traps. exFAT reports itself as Windows_NTFS in diskutil list because the two share a partition type byte — I took that apart while chasing the error code behind a portable SSD that would not mount. And the chmod 600 column is not a rounding error: exFAT and the FAT family do not store POSIX permissions at all, so macOS synthesises 700 for every file and silently discards whatever you set.

Allocation blocks: the bill nobody itemises

Here is the test that changed how I'd answer this question. I wrote 1,000 files of one byte each — 1,000 bytes of actual payload — onto an 8 GB volume of each format, and measured the change in df -k.

The ratio gets worse on a drive you'd actually buy, because macOS scales the cluster size with the volume. I created sparse images at three realistic capacities and read the allocation block straight out of diskutil info:

Volume size	ExFAT	MS-DOS (FAT32)	APFS
128 GB	131,072 B (128 KiB)	32,768 B	4,096 B
512 GB	131,072 B (128 KiB)	32,768 B	4,096 B
2 TB	131,072 B (128 KiB)	32,768 B	4,096 B

Format a 2 TB external SSD as ExFAT and every file, however small, is billed in 128 KiB units — thirty-two times APFS's block. Ten thousand small text files can cost over a gigabyte of nothing. This is why users keep reporting that their folders got smaller after copying from exFAT to APFS with the file count unchanged; the accepted answer there is a correct but unquantified "files on exFAT take more space than APFS."

Timestamps drift by format, and backups notice

I set an mtime of 1755000001.123456789 on a file in each volume and read it back with stat -f %Fm:

• APFS: 1755000001.123456789 — every nanosecond preserved.
• ExFAT: 1755000001.120000000 — rounded to 10 ms.
• Mac OS Extended (Journaled): 1755000001.000000000 — rounded to 1 second.
• MS-DOS (FAT32/16/12): 1755000000.000000000 — the odd second was rounded down to an even one.

That last line is FAT's two-second granularity showing itself, and the ExFAT result is that same clock with a finer vernier on top: the Microsoft exFAT specification builds on a two-second timestamp base and adds optional ten-millisecond increment fields. A measured floor of exactly 10 ms is what that design predicts, and it is what I got.

This is not trivia if you sync. Any tool that decides "changed or not" by comparing modification times — rsync, most backup scripts, plenty of build systems — compares a nanosecond source against a 2-second destination. Files get recopied, or worse, skipped.

Sparse files are an APFS-only feature

I created a 1 GiB hole (dd with seek=1073741824, one byte written) and measured actual allocation with stat -f %b. APFS and APFS (Case-sensitive) stored it in 8 blocks — 4 KiB. ExFAT, FAT32 and both HFS+ variants allocated the whole gigabyte: 2,097,160 to 2,097,216 512-byte blocks. FAT16 and FAT12 refused to create the file at all.

If you store disk images, database files or VM volumes externally, that is the difference between a 4 KiB file and a 1 GiB one — and why the 2x rule for Time Machine drive sizing counts different things depending on the format underneath it.

What Time Machine will actually accept

Apple's own documentation is unambiguous and worth quoting rather than paraphrasing. From Types of disks you can use with Time Machine on Mac: "APFS or APFS Encrypted disks are the preferred format for a Time Machine backup disk." It still supports the old ones — "Mac OS Extended format (Journaled), Mac OS Extended (Case-sensitive, Journaled), and Xsan formatted disks" — and it rules out the rest: "Time Machine can't back up to iPhone, iPad, or iPod or to a disk formatted for Windows."

So which one

• Mac-only, including Time Machine → APFS. It is the only format here with sparse files and nanosecond timestamps, it has the smallest allocation block, and it is what Apple says Time Machine prefers.
• Shared with Windows → ExFAT, knowingly. You are paying 128 KiB per file, losing POSIX permissions and hard links, and giving up journaling. Non-journaled volumes must be ejected properly or they corrupt — and when they do, exFAT is the one that fails to repair while HFS+ recovers.
• Mac OS Extended (Journaled) only for a drive that must be readable by a Mac running something older than Big Sur.
• Never MS-DOS (FAT32/16/12) on an SSD. The 4 GiB file ceiling is real and it is theirs.
• Case-sensitive variants only if you know you need them. They break some Mac software that assumes otherwise.

Portable SSDs generally arrive ExFAT-formatted from the factory — the Crucial X10 Pro datasheet says so in a footnote and Apple Discussions threads report the same for Samsung's drives — so reformatting is a step you should plan on, not an exception. If you are buying one for this, the Samsung T9 2TB is the drive I referenced while working through which portable SSD suits a Mac mini; I don't own it, so treat that as a pointer, not a review.

The commands

# See what your Mac will actually offer
diskutil listFilesystems

# Find the disk (check the size twice — erasing is not undoable)
diskutil list external

# APFS, GUID partition map — the Mac-only default
diskutil eraseDisk APFS Backup GPT /dev/diskN

# ExFAT, for a drive you share with Windows
diskutil eraseDisk ExFAT Shared GPT /dev/diskN

# Verify what you got
diskutil info /Volumes/Backup | grep -E 'Personality|Allocation Block'

The Amazon link above is an affiliate link: if you buy through it I earn a commission at no extra cost to you. Sourcing for this piece: every number in the tables and the chart is my own measurement, taken on 2026-08-20 on a Mac mini M4 running macOS 26.4.1 (25E253), using hdiutil sparse images rather than a physical drive — I own no external storage, which is why there are no throughput or thermal figures here. The scripts were run three times; the second and third runs exist because the first produced a false "exFAT can't hold a file over 4 GiB" result that I've documented above rather than quietly dropped. Time Machine's format support is quoted verbatim from Apple's documentation, the 2-second and 10 ms timestamp granularities are cross-checked against Microsoft's exFAT specification and published forensic analysis of it, and the user reports of shrinking folders and stale Catalina advice are linked to the original threads. I did not run tmutil setdestination to confirm Apple's list, because it requires root and would alter this machine's live backup configuration.

Update 2026-08-20 — One caveat to the format-choice framing here: when a drive is already read-only, the format is often not the variable. Across the five top guides for that symptom, five of five blame NTFS and none of five tell you to check whether the storage device itself is refusing writes. I ran that battery separately in external hard drive read only on Mac, and the two bits that decide it, which also finds that the built-in NTFS mount path is gone on macOS 26.4.1.