ditto vs zip vs tar on macOS

Files on macOS carry more data than what you see in Finder. Beyond the file content there is metadata - and not all archiving tools preserve it. This has been a source of subtle bugs for decades.

Resource forks and extended attributes

Back in the classic Mac OS days, files had resource forks - a second data stream that stored structured metadata like icons, dialog layouts, or code. This was a feature of the HFS file system and pretty unique to the Mac.

When Apple moved to Mac OS X and eventually to APFS, resource forks didn’t really disappear. They evolved into extended attributes. Arbitrary key-value pairs attached to any file. APFS supports them natively, and macOS uses them everywhere.

Some concrete examples of extended attributes you encounter daily:

com.apple.quarantine is the flag that triggers “this file was downloaded from the internet” warnings
com.apple.metadata:kMDItemWhereFroms records which URL a file was downloaded from
com.apple.FinderInfo stores Finder tags and other Finder-specific metadata

You can inspect them with the xattr command line tool:

$ xattr -l sample.txt
com.apple.quarantine: 0081;12345678;Safari;ABC123
user.custom: my-custom-value

Other operating systems have similar concepts. Linux has extended attributes via getfattr and setfattr (used by SELinux for security labels, for instance). Windows has alternate data streams on NTFS. But macOS relies on them more heavily than most, which is why archiving them matters.

The archiving problem

Not all archive tools treat extended attributes the same way. Checking the behaviour of zip, ditto, and tar on macOS 15 (Sequoia) reveals some interesting differences.

zip

$ zip -r archive.zip testfolder/
$ unzip -l archive.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
       12  02-23-2026 23:42   testfolder/sample.txt
---------                     -------
       12                     1 file

Standard zip creates a clean, portable archive. But it drops extended attributes. What you get back after extracting is the file content - nothing more.

ditto

$ ditto -ck testfolder archive.zip
$ unzip -l archive.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
       12  02-23-2026 23:42   sample.txt
      264  02-23-2026 23:42   ._sample.txt
---------                     -------
      276                     2 files

ditto is what Finder uses when you right-click and choose “Compress”. It stores extended attributes in AppleDouble ._ files alongside the actual content. On a Mac, extracting this archive restores the full metadata. This has been the default behavior since Mac OS X 10.4.

The catch: when someone unpacks a ditto archive on Linux or Windows, those ._ files just show up as regular files. Annoying and unexpected for the non-Mac users.

tar (bsdtar)

$ tar -cf archive.tar testfolder/
$ tar -tf archive.tar
testfolder/
testfolder/sample.txt

The tar that ships with macOS is actually bsdtar, not GNU tar. And it preserves extended attributes by default - no special flags needed. The metadata is stored natively in the archive format.

# disable metadata explicitly if you don't want it
$ tar --no-mac-metadata -cf clean.tar testfolder/

This makes tar a solid choice when you’re archiving on a Mac for use on a Mac. The metadata travels with the archive transparently and doesn’t produce any ._ clutter.

Quick comparison

Tool	xattrs	Format	Cross-platform
`zip`	no	zip	clean everywhere
`ditto -ck`	yes	zip (with `._` files)	`._` files on non-Mac
`tar` (bsdtar)	yes	tar (native metadata)	only macOS bsdtar restores metadata
`tar --no-mac-metadata`	no	tar	clean everywhere

When to use what

Sharing with non-Mac users? Use zip or tar --no-mac-metadata. The ._ files from ditto archives tend to cause confusion on the receiving end.

Archiving for yourself or other Mac users? Use ditto -ck or just tar. Both preserve the full metadata. ditto gives you a zip that Finder can preview, tar is more natural for the command line.

Backing up files where metadata matters? tar is the first choice. It preserves everything without the ._ file overhead. Though for real backups you probably want Time Machine or tmutil, which handle extended attributes as well.

For the last 20 years the advice has been to use ditto over zip. That hasn’t changed. But it’s worth knowing that tar on macOS has quietly become a solid alternative that avoids the trade-off entirely.

TLDR: Don’t use zip if metadata matters. Use ditto for zip archives, tar for everything else.