Sustainability of Digital Formats: Planning for Library of Congress Collections

Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact
Format Description Categories >> Browse Alphabetical List

AppleDouble Resource Fork

>> Back
Table of Contents
Format Description Properties Explanation of format description terms

Identification and description Explanation of format description terms

Full name AppleDouble Resource Fork

AppleDouble Resource Fork files are system communication files created by Apple's macOS or OS X operating systems. These files hold Apple system metadata about their corresponding file. They are typically invisible to macOS users. These files may be colloquially referred to as Dot Underscore files due to the files always beginning with "._". According to Apple, they appear visible when files created on Apple-based operating systems and subsequently are saved or moved to non-macOS storage drives such as (link via Internet Archive) remote NFS, SMB, WebDAV directories, or local UFS volumes.

Apple Computer, Inc. introduced AppleDouble and sibling AppleSingle with the intent of representing files on non-Apple file systems while also preserving all attributes of the file's home system. These files exist in order to avoid complications in storing different parts of a Macintosh file in a non-Macintosh file system that can only handle consecutive data in one part. Therefore it is common to convert the Macintosh file into some other format before transferring it over the network. These two methods are AppleSingle and AppleDouble.

As documented by the AppleSingle/AppleDouble Formats for Foreign Files Developer's Note, the AppleSingle or AppleDouble format can be used:

  • 1. as a standard format for transferring files among differing, or heterogeneous, computers.
  • 2. as a standard format for transferring files within a single computer.

AppleSingle and AppleDouble formats use the same components to represent a file on a foreign system: data, resources, and attributes. The difference between the two formats is that the AppleSingle format stores these components in a single foreign file, and the AppleDouble format stores these components in two foreign files—one for the data, the other for the resources and attributes.

As outlined in the Developer's Notes, applications may use either AppleSingle or AppleDouble when they create files on foreign file systems, but applications must understand both formats.

AppleDouble Resource Fork files use two files to store data, resources, and attributes: The Data fork and the Resource fork. The AppleDouble Data file contains the Data fork and the AppleDouble Header file contains the Resource fork.

The AppleDouble Data file contains the standard Macintosh data fork with no additional header. This is the meaningful part of a file when read on a non-Macintosh filesystem, as it holds unstructured file data. The data fork contains data specific to an application.

RFC1740 notes the AppleDouble Header file contains the Resource fork holds a structured collection of attribute/value pairs, including program segments, icon bitmaps, and parametric values. The resource fork contains data used by an application, such as menus, fonts, and icons. An executable file's code is also stored in the resource fork.

The AppleDouble Header file is structured exactly the same as the AppleSingle format, defined in the same specification, with one exception: it does not contain a data fork entry.

RFC 1740 considers AppleDouble to be the preferred format for a Macintosh file that is intended to be sent in an Internet mail message because it provides recipients with Macintosh computers the entire document, including Icons and other Macintosh specific information, while other users easily can extract the Data fork (the actual data) as it is separated from the AppleDouble encoding.

When moving files away from earlier macOS systems, there is a possibility (link via Internet Archive) that the resource fork can be lost, according to Apple. When dealing with non-forked file systems, AppleDouble converts the file into two separate files. The first new file keeps the original name and contains the data fork of the original file. The second new file has the name of the original file prefixed by a "._ " and contains the resource fork of the original file. The ._ file can safely be ignored. Deleting the ._ component will have no effect on the non-macOS hard drive, but some metadata may be lost if the file is moved back to macOS.

Locations for AppleDouble files take several forms. To summarize the ArchiveTeam wiki entry, they can be in a subdirectory called ".AppleDouble" or "__MACOSX", or just alongside the files they are describing.

AppleDouble Header file entries can appear in any order. However, Apple recommends that the resource fork entry be placed last in the file because the resource fork is the entry in the Header that is most commonly extended.

AppleDouble Resource Fork filenames are created based on the operating system that is reading them, so it depends on the file system. This also means that these files will appear differently on different file systems. To summarize, ProDOS: Data files will be 13 alphanumeric characters and Header files will start with "R." For MS-DOS: Data files will be 8 alphanumeric characters and include a file extension "most appropriate for the file" and Header files will have the extension .ADF. (short for "AppleDouble File", as per the spec). For UNIX/NFS file systems, it follows the file system naming convention, either 8bit, 7-bit ASCII, or 7-bit alphanumeric. Names of the data files will be contingent on these details. Header files will match the Data file name but be prepended with a "%". More details can be found in the "Filenaming conventions" section of the Developer's Notes.

Apple's Developer Notes state that AppleSingle files can be updated to AppleDouble files by performing the following steps:

  • 1. Overwrite the version number and filler fields in the AppleSingle or AppleDouble file header.
  • 2. Replace the File Info entry (ID=7) in the version 1 file with the File Dates Info entry (ID=8) and one of the following entry IDs: Macintosh File Info (ID=10), ProDOS File Info (ID=11), or MS-DOS File Info (ID=12).
Production phase Used by Mac operating systems as part of production.
Relationship to other formats
    Affinity to AppleSingle Format. Apple's standard format for encoding Macintosh files as one byte stream. AppleSingle format is described in the same specification as AppleDouble, for both versions 1 and 2. Usage for both is defined in IETF RFC 1740. Not described on this site at this time.

Local use Explanation of format description terms

LC experience or existing holdings The Library of Congress has AppleSingle and AppleDouble resource forks in personal papers collections, especially in the Manuscript Division. See An Archivist’s Perspective on Legacy Files (Nov 2020) for more discussion.
LC preference

The Library of Congress Recommended Formats Statement has not yet expressed any format preference for system files.

Sustainability factors Explanation of format description terms

Disclosure Not officially disclosed. Proprietary format developed by Apple, Inc. Some documentation available.

Apple provided a document entitled AppleSingle/AppleDouble Formats for Foreign Files Developer's Note for understanding and parsing AppleDouble Resource Fork files. This resource is cited directly in the IETF RFC 1740. Apple also provided a brief summary (link via Internet Archive) of what the AppleDouble Resource Fork format entails. Comments welcome.

Adoption Used by all macOS systems in communication with other filesystems.
    Licensing and patents

The AppleDouble Resource Fork file format is not explicitly associated with any specific license or patent. It is a proprietary file format created by Apple Inc. However, there is no public documentation or specification provided by Apple regarding the AppleDouble Resource Fork file format.

As a proprietary format, the usage, distribution, and analysis of AppleDouble Resource Fork files are subject to Apple's terms of service and intellectual property rights.


The Developer's Note has detailed documentation on how to build applications that can read and write AppleDouble Resource Fork files.

IETF RFC 1740 has an Appendix C that includes a C (programming language) header file that is an example of parsing AppleDouble files. This C header file example in IETF RFC 1740 points out that some parts of the specification are ambiguous

The Perl module Mac::AppleSingleDouble can be used for reading files.

Self-documentation Little to none. Comments welcome.
External dependencies AppleDouble Resource Fork files exist in between the relationship of a macOS file system in communication with non-macOS file systems (DOS, UNIX, et al).
Technical protection considerations None. Comments welcome.

Quality and functionality factors Explanation of format description terms

File type signifiers and format identifiers Explanation of format description terms

Tag Value Note
Filename extension See note.  None. AppleDouble Resource Fork files do not have a traditional file extension. According to PRONOM, the format lacks an extension, and is instead represented by a file name consisting of ._<filename resource fork belongs to>"
Internet Media Type multipart/appledouble

Defined in IETF RFC 1740. See also IANA. The RFC states

  • The AppleDouble file should be sent as a "multipart/appledouble" MIME body.
  • The header should be sent as "application/applefile".
  • The data fork should be sent as whatever best describes it. For example, if the data is a GIF image, the data fork value should be sent as "image/gif". If no appropriate Content-Type has been registered for the data type, it should be sent as "application/octet-stream".
Magic numbers 0005160700010000

The specification notes that the AppleDouble format's magic number string is 00051607. Following the magic number string is another string, 00010000, that represents the file version. Thus, the string 0005160700010000 represents AppleDouble Resource Fork 1.

Magic numbers 0005160700020000

The specification notes that the AppleDouble format's magic number string is 00051607. Following the magic number string is another string, 00020000, that represents the file version. Thus, the string 0005160700020000 represents AppleDouble Resource Fork 2.

Pronom PUID fmt/966
AppleDouble Resource Fork 1. See
Pronom PUID fmt/503
AppleDouble Resource Fork 2. See
Wikidata Title ID Q27578076
AppleDouble Resource Fork, version 1. See
Wikidata Title ID Q27578083
AppleDouble Resource Fork, version 2. See

Notes Explanation of format description terms


The AppleSingle and AppleDouble formats were developed to store macOS files on file systems with non-macOS file structures. This was to prevent loss of a file's metadata or other attributes when moving files from macOS to other file systems and back to macOS systems. The specification was written in 1990. RFC 1740 was written/finalized in 1993, with some edits into 1994.

Format specifications Explanation of format description terms

Useful references


Last Updated: 04/19/2024