Finding Type/Creator Tags in Old Mac Document Files

I saved old files from my Mac Plus days and I’d like to open them with applications running under Monterey.

Of course, in the old days files didn’t need extensions and I didn’t include them in file names. Now many of these these files without extensions are displayed as “exec” files in the Finder and double clicking on them is of no value. Some files say “ Microsoft Word 1.x-5.x document” in the Kind field of a Get Info window, but most just say “Document” and give no indication what application produced them.

If I open the files in BBEdit, sometimes I get a hint of the application that created them. For example, some files have the plain text “SIT” near the beginning. Sure enough, adding a file extension of .sit allows me to open these archives with BetterZip.

Can anyone think of a way to figure out what application can open an old Mac document file? I was thinking that the best way of identifying the associated application for an old document file would be to extract the Type/Creator tags.

Does anyone know how to extract Type/Creator tags with an app that runs on Monterey?

Thank you.

1 Like

Both PathFinder ( and A Better Finder Attributes ( can work with type and creator codes for old files. It’s up to the user to research what apps are associated with what codes, but the codes themselves are available. I’ve found that the two are best used in conjunction with each other, as each is suitable for different tasks.

Libre Office is my can-opener. Especially for word processing files, it pulls the text and maybe some formatting for almost any word-processing file back to MacWrite (including the inscrutable WriteNow). It’s donationware, so give it a whirl .

There is no need to play with type and creator codes. Just open the program and then open the file in question. It will give you something to play with more often than not.


Turns out that I already have PathFinder as a result of a software bundle I bought in December. Now I have a use for it!

Not only does it exhume the Creator tag, it even displays the application icon occasionally.

Thank you.

1 Like

In my experience, this is a problem that appeared after I upgraded from Mojave (10.14) to Monterey (12). In Mojave, I would get sensible file types and icons for my older files with type/creator codes and no extensions. But now, even when the Mac understands the document type based on the type/creator codes, it displays the wrong icon. And even then, it displays a different incorrect icon for different files, with seemingly no reason:



But to answer your question about how to access type/creator codes, Apple actually provides a command line tool for this called GetFileInfo:

> GetFileInfo Initial\ letter\ to\ Prof\ Smyth
file: "/Users/me/Documents/Correspondence/Letters/Initial letter to Prof Smyth"
type: "WPD3"
creator: "WPC2"
attributes: avbstclInmedz
created: 05/18/2002 13:08:02
modified: 05/18/2002 13:08:02

You can get just the type code or just the creator code:

> GetFileInfo -t Initial\ letter\ to\ Prof\ Smyth
> GetFileInfo -c Initial\ letter\ to\ Prof\ Smyth

So it would be relatively simple to create a script (e.g. in AppleScript) that you could drop a file or files on, and it would extract the type & creator codes, look up the document type associated with them, and append the appropriate extension to the file.

You would have to manually create this lookup table, and there is no ‘master list’ to get the type/creator codes from. But there are some lists already on the web that most likely cover any file you’re likely to come across. And any files you have not on these lists, you could do a search and find out what they are. (As an aside, a lot of the creator codes can be guessed from the letters used, but some are ‘obvious’ only because they became well known, like BOBO for ClarisWorks/AppleWorks and R*ch for BBEdit.)

[Pythonmac-SIG] Discovering file type
Mac Creator and File Type codes

(As a final aside, Apple also provides the corresponding SetFile command line utility, so creating reverse script – assigning type/creator codes based on filename extensions – would also be possible.)


HexEdit provides creator and type codes in the header of its display for a file:

Kids Nov92 HEX KKC2 copy

1 Like

Over in Windows, how can I determine the Mac type code? I have a large number of complicated data files, and the type code identifies an internal format. Here’s the thing though: I can move such a file to Win, duplicate it or copy and paste it elsewhere, and then move that copy back to my Mac. But that file that had been duplicated on the PC has the same original creator and type codes. That suggests it exists SOMEWHERE even while living on the PC. But where? (Thanks!)

Yes, this works perfectly with my old (late 80s to early 90s) Microsoft Word files.

The type/creator codes are not part of the file, but are separate “Finder Info” data. Mac file systems (HFS, HFS+ and APFS) store this data along with a file’s data and any forks (e.g. resource fork) that might also be associated with the file.

When macOS saves a file with Finder data, extended attributes or forks to a non-Mac file system (e.g. FAT, or to a network volume), this metadata (along with the contents of any resource fork data that might exist) gets copied to a hidden file that has the same name as the original file, with a ._ prefix.

As a quick demonstration, create a Microsoft Word document and save it to a Mac location (e.g. ~/foo.docx). Note the type/creator codes on the document:

$ GetFileInfo foo.docx 
file: "/Users/.../foo.docx"
type: "WXBN"
creator: "MSWD"
attributes: avbstclinmedz
created: 08/21/2022 18:24:31
modified: 08/21/2022 18:24:31

Also note that there is no corresponding ._ file (actually, no ._ files of any kind) in that directory:

$ ls -la ._*
ls: No match.

That’s because Mac file systems (HFS, HFS+ and APFS) support this data as a native part of the file system and therefore don’t store it separately.

Now, use the Finder to copy that document to a non-Mac volume (I’m using a USB hard drive formatted as exFAT) and repeat the above:

$ cd "/Volumes/David C"
$ GetFileInfo foo.docx 
file: "/Volumes/David C/foo.docx"
type: "WXBN"
creator: "MSWD"
attributes: avbstclinmedz
created: 08/21/2022 18:24:31
modified: 08/21/2022 18:24:31

$ ls -la ._*
-rwxrwxrwx  1 ...  staff  4096 Aug 21 18:29 ._foo.docx

This ._ file contains the file’s Finder metadata and any resource fork data (and any other forks) that might also be associated with the file. A Mac will know to look for this file, which is why GetFileInfo still works:

You can dump its contents to see what’s inside:

$ hexdump -C ._foo.docx
00000000  00 05 16 07 00 02 00 00  4d 61 63 20 4f 53 20 58  |........Mac OS X|
00000010  20 20 20 20 20 20 20 20  00 02 00 00 00 09 00 00  |        ........|
00000020  00 32 00 00 0e b0 00 00  00 02 00 00 0e e2 00 00  |.2..............|
00000030  01 1e 57 58 42 4e 4d 53  57 44 00 00 00 00 00 00  |..WXBNMSWD......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 41 54 54 52  00 00 00 01 00 00 0e e2  |....ATTR........|
00000060  00 00 01 34 00 00 00 b3  00 00 00 00 00 00 00 00  |...4............|
00000070  00 00 00 00 00 00 00 04  00 00 01 34 00 00 00 20  |...........4... |
00000080  00 00 15 63 6f 6d 2e 61  70 70 6c 65 2e 71 75 61  ||
00000090  72 61 6e 74 69 6e 65 00  00 00 01 54 00 00 00 10  |rantine....T....|
000000a0  00 00 1a 63 6f 6d 2e 61  70 70 6c 65 2e 6c 61 73  ||
000000b0  74 75 73 65 64 64 61 74  65 23 50 53 00 00 00 00  |tuseddate#PS....|
000000c0  00 00 01 64 00 00 00 2a  00 00 24 63 6f 6d 2e 61  |...d...*..$com.a|
000000d0  70 70 6c 65 2e 6d 65 74  61 64 61 74 61 3a 5f 6b  |pple.metadata:_k|
000000e0  4d 44 49 74 65 6d 55 73  65 72 54 61 67 73 00 00  |MDItemUserTags..|
000000f0  00 00 01 8e 00 00 00 59  00 00 37 63 6f 6d 2e 61  |.......Y..7com.a|
00000100  70 70 6c 65 2e 6d 65 74  61 64 61 74 61 3a 6b 4d  |pple.metadata:kM|
00000110  44 4c 61 62 65 6c 5f 6f  66 66 32 74 33 34 64 33  |DLabel_off2t34d3|
00000120  75 74 70 35 6f 37 76 73  77 70 70 66 61 72 68 72  |utp5o7vswppfarhr|
00000130  79 00 00 00 30 30 38 32  3b 36 33 30 32 62 30 39  |y...0082;6302b09|
00000140  66 3b 4d 69 63 72 6f 73  6f 66 74 5c 78 32 30 57  |f;Microsoft\x20W|
00000150  6f 72 64 3b 9f b0 02 63  00 00 00 00 66 9a 4f 18  |ord;...c....f.O.|
00000160  00 00 00 00 62 70 6c 69  73 74 30 30 a0 08 00 00  |....bplist00....|
00000170  00 00 00 00 01 01 00 00  00 00 00 00 00 01 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 09 f2 8a  |................|
00000190  e8 14 f6 73 bd 4a 7d d8  21 e3 ac e3 1c 5d ff 2b  |...s.J}.!....].+|
000001a0  b6 18 5c 7e 64 9f bf 7a  8a 7b 7a 8f 03 ff 38 03  |..\~d..z.{z...8.|
000001b0  d6 b5 40 7f c9 68 33 2c  8f f6 35 80 70 77 42 5f  |..@..h3,..5.pwB_|
000001c0  0d ae 68 66 f7 f1 fe 6e  0b c5 eb 43 7a 50 93 95  |..hf...n...CzP..|
000001d0  bb 40 65 df 61 ee 12 82  f5 77 79 1d a8 ed 86 a7  |.@e.a....wy.....|
000001e0  fa 4d 2c d2 2d 7a 4b 00  00 00 00 00 00 00 00 00  |.M,.-zK.........|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000ee0  00 00 00 00 01 00 00 00  01 00 00 00 00 00 00 00  |................|
00000ef0  00 1e 54 68 69 73 20 72  65 73 6f 75 72 63 65 20  |..This resource |
00000f00  66 6f 72 6b 20 69 6e 74  65 6e 74 69 6f 6e 61 6c  |fork intentional|
00000f10  6c 79 20 6c 65 66 74 20  62 6c 61 6e 6b 20 20 20  |ly left blank   |
00000f20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000fe0  00 00 00 00 01 00 00 00  01 00 00 00 00 00 00 00  |................|
00000ff0  00 1e 00 00 00 00 00 00  00 00 00 1c 00 1e ff ff  |................|

Note, among other things, the type/creator fields (WXBNMSWD at offset 0x32) and various extended attribute names (e.g. and In general, it will have all of the file’s content that is not part of the its data fork.

If you use the Finder to copy the file back to a Mac from the non-Mac volume, it will see this file and will use it to re-create the Finder info and resource fork on the Mac volume.

Non-Mac systems can copy this file all over the Internet and this metadata will be preserved as long as the corresponding ._ file is copied with it at all times.

If, however, you were to copy the file without its ._ file (or just delete it), then that metadata will get lost. Which you can demonstrate:

$ rm ._foo.docx 

$ GetFileInfo foo.docx 
file: "/Volumes/David C/foo.docx"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 08/21/2022 18:24:31
modified: 08/21/2022 18:24:31

Notice how type/creator information is no longer available. MacOS will still be able to associate the document with Microsoft Word because of the file extension, but that will now be the only possible way. (Word will be able to open it because Microsoft doesn’t store document data in the resource fork.)

This, BTW, is why it is recommended you package Mac files using something like a disk image or a zip file. This will ensure that the metadata and resource fork get packaged with the rest of the file. This way, no matter how many times is is copied and moved using non-Mac systems, when a Mac user downloads the package, the metadata will be there.

There are, of course, other mechanisms for packaging info/resource data with files, but most of them are only of historic interest these days (e.g. BinHex, MacBinary, AppleSingle and AppleDouble (macOS’s current system of using ._ files is a variation of AppleDouble).


David, I can’t thank you enough for that explanation. I’m going to copy and save this for future reference.

HOWEVER, there are still mysteries. Here’s what I tried for a sample file “sample” that I know has type and creator codes:

  1. On the Mac, I copied that file over to a directory on a PC running Windows 10
  2. Moving over to that PC, I made sure that View>Hidden Items is CHECKED.
  3. The directory lists a “.DS_Store” in some folders, so I know I can now see hidden “.” files
  4. Going to the directory where I moved that file “sample” from the Mac, I see that file, but I do NOT see ANY “.” files.
  5. As a double-check, I add a line to my code (in Delphi) using FileExists to look for “._sample” in the same directory. I confirm that this file does NOT exist.

This is MYSTERY #1: where is the “._sample” file I was expecting?

  1. Still in Windows, I did a copy to attempt to further disrupt any connection between the data file and some lurking invisible file: I did right-click>Copy on that data file, then I created a new folder and did a right-click Paste into there.
  2. Moving back to the Mac, I explore that new folder and file on the PC.
  3. Using HexEdit, I see that this new file has the creator and type codes!!!

That’s Mystery #2: It sure looks like Copy and Paste on Windows somehow preserved the type and creator code info. It looks like Win somehow is agreeable enough to do something useful with this Macish information.

I welcome your thoughts, and thanks again for the information!

This surprised me, so I looked a bit closer.

The reason is because NTFS (which I assume your Windows file system is using) has support for multiple forks (which Microsoft calls alternate data streams (ADS) ) and Windows file sharing supports ADS. When you copy a file from a Mac to a network volume that supports ADS, macOS will create streams/forks to store the file’s Finder metadata, extended attributes and resource forks.

I ran a quick test. As before, I created a Word document. This time, instead of copying it to a FAT-formatted storage device (which has no support for ADS), I copied it to a Windows 10 file share, to a directory on an NTFS volume.

From a Windows command prompt, if you type dir to view the document, you will only see the file’s primary data stream (what Apple calls the data fork):

C:\Users\...\tmp> dir
 Volume in drive C has no label.
 Volume Serial Number is DA9A-72B5

 Directory of C:\Users\...\tmp

08/22/2022  11:27    <DIR>          .
08/22/2022  11:27    <DIR>          ..
08/22/2022  11:26            11,878 foo.docx
               1 File(s)         11,878 bytes
               2 Dir(s)  56,669,786,112 bytes free

But if you use the /R option, the dir command will show you any alternate data streams, and in this case, there are several:

C:\Users\...\tmp> dir /r
 Volume in drive C has no label.
 Volume Serial Number is DA9A-72B5

 Directory of C:\Users\...\tmp

08/22/2022  11:27    <DIR>          .
08/22/2022  11:27    <DIR>          ..
08/22/2022  11:26            11,878 foo.docx
                                 60 foo.docx:AFP_AfpInfo:$DATA
               1 File(s)         11,878 bytes
               2 Dir(s)  56,669,786,112 bytes free

Apps that are ADS-aware can open these alternate streams. The filename for each stream is what you see in the directory listing, but without the :$DATA suffix. One app bundled with Windows that is ADS aware (and can therefore read them) is Notepad:

C:\Users\...\tmp> notepad foo.docx:AFP_AfpInfo

And if you do this, you’ll see that the AFP_AfpInfo stream contains the Finder info, including the type/creator codes:


(Do not save this file!. These streams contain binary data and Notepad is a text editor. If you try to save to the stream, you will probably corrupt it.)

The other named data streams almost certainly contain the file’s other extended attributes (which you can see in my previous post, as a part of the hex-dump of the ._ file):


(The : character gets converted to a private-use Unicode character (U+F022: ), because colons are invalid filename characters on Windows.)

See also: How to Create, Open, Detect, and Remove Alternate Data Streams


Stunner info, David, I can’t thank you enough! Best of all, with your info I was indeed able to coax my program into reading those “alternate” files. That makes things much simpler and safer. It’s quite an irony that Apple dispenses ideas that Microsoft then picks up.

@nello, I realise that your immediate issue has likely passed and there are various solutions given in this thread. However, I’m reviving it as I just read a great article on Howard Oakley’s website about how MacOS determines file types. It’s a well written, clear and concise article on the topic:

How does macOS tell the type of a file? – The Eclectic Light Company

It also includes links to a couple of very useful utilities for quickly determining the type of a file, and seeing what metadata is being used to make that determination:

Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma – The Eclectic Light Company

Thomas Tempelmann - Launch Services


I use Super Get Info if I need to know for an individual file what its Creator and Type codes are. My own question is – let’s suppose I want to search my hard drive for all files with Creator “MACA” and Type “WORD”. The native Command-F finding utility of the Finder no longer offers it even among the arcane things it is willing to bring up under “Other”.

What’s a good tool for searches of this general ilk?

1 Like

Find Any File does this well, as well as being able to search on many other criteria:

You can combine multiple criteria, including using nested AND/OR combinations.


Aah, thanks! Someone else on a different message board had suggested that, but, umm, Google Advanced Search ain’t what it used to be, and “find any file” is way too generic a phrase to hunt down an application of that name. Appreciate the direct link!


1 Like

Lots of great posts on this thread!

I’ll add two utilities to the list of apps that can make it easier to do batch operations involving file attributes (like “type” and “creator”) and names/tags:

A Better Finder Attributes
A Better Finder Rename

I probably use them only once or twice a year, but when I do, they can save me a lot of time. If you find yourself routinely doing a particular type of file manipulation, they also can make “droplets” to allow drag-and-drop modifications.

1 Like

Glad I could help! At the risk of taking things off topic, I find that DickDuckGo is great for this sort of thing as seems is less likely to fall victim to gaming search results or try to ‘personalise’ results for you. In this case the link to the correct website is the top result: