リソースフォーク（）は、Classic Mac OS特有のファイルの構造であり、実際のデータを表すデータフォークとは別に、アイコンやウィンドウの形状、メニューの内容や定義、古くはアプリケーションコード（機械語）などといった、フォーマットがある程度定型化された情報を持つ。また、情報そのもののことをとくに「リソースデータ」という。リソースフォークの存在によりデータにさまざまな付加情報を簡単に記録することができる。これに対して、実際のデータ部をとくに「データフォーク」と呼ぶ。データフォークは、Windowsにおけるメインデータストリームなど、Classic Mac OS以外のオペレーティングシステム (OS) でデータを記録する部分と同じである。Windowsにも似た機能を持つリソースという概念はあるが、Classic Mac OSのそれとは異質のものである。

Classic Mac OSではこの他にもFinder情報と呼ばれるメタデータがある。現在のmacOSではリソースフォークとFinder情報を拡張属性 (EA) として扱うようになった。

 対応システム 
リソースフォークはHFSやHFS+と呼ばれるファイルシステムやAFPと呼ばれるファイル共有プロトコルだけがサポートしている。これらのファイルシステムやファイル共有プロトコルは現在のところClassic Mac OSだけがサポートしているため、事実上Classic Mac OSだけの機能になっている。一方、Classic Mac OSはUFSと呼ばれるファイルシステムにインストールして使用することもできる。この場合、リソースフォークを実際のデータとは別のファイルに分離することにより管理している。

現在のMac OSで最も利用されているHFS+では、データフォークとリソースフォーク以外のフォークも扱えるように設計されており（マルチフォーク）、macOS（v10.3以降）では、マルチフォークの機能を利用して、ファイルに拡張属性を付加したり、アクセス制御リストによるセキュリティ機能が提供されている。

Windows NT以降で採用されたファイルシステムであるNTFSでは、代替データストリームが利用出来るため、これを用いてリソースフォークを保存する事が出来る。SFM (Service for Macintosh) を使ってClassic Mac OSからWindowsにファイルを転送した場合、これが利用される。

 リソースフォークの編集 
リソースフォークはResEditなどのリソースエディタと呼ばれる部類のエディタで編集することが出来るため、ソフトウェアのローカライズやカスタマイズが行える。また、大抵のリソースエディタは視覚的にデータを編集できる。また、Appleが無償で提供する統合開発環境、 (MPW) やApple Developers ToolsにはRezと呼ばれるコンパイラが存在し、Rez専用の言語（これもRezと呼ばれる）で記述されたソースコードをコンパイルすることでリソースフォークを作成することも出来る。逆に、リソースフォークからRezコードに戻すための逆コンパイラ、DeRezも同梱されている。

ただし、リソースフォークの編集は、場合によってはファイルを破壊しかねないので、構造を理解したうえで、自己責任で行う必要がある。

 リソースフォークの構造 
リソースフォークの構造は、リソースデータの配置を記録する「リソースマップ」と呼ばれるデータがあり、これによりリソースデータに定義されたIDや名前によってランダムアクセスを容易にしている。それとは別に実際のデータとなるリソースデータが記録され、大まかに分けてこの二つで構成されているが、実際には一つのタイプに複数のデータを記録できる階層構造になっている。リソースデータは、記録する情報の種類によって情報の記録形式が定義されており、その種類のことを「リソースタイプ」という。なお、リソースタイプは自分で自由に定義できる。また、リソースデータは他のタイプのデータを参照していることがよくある。

 ヘッダ（リソースデータおよびリソースマップの開始位置や長さなどを記録）
 リソースデータ（実際のデータ。データの先頭4バイトにデータ長を記録している。データごとに複数個存在する）
 リソースマップ（リソースデータがどこに記録されているかなどを記録。内部は以下のようになっている）
 リソースタイプリスト（どのようなリソースタイプが使用されているかなどを記録）
 リソース参照リスト（指定IDが持つリソースデータの開始位置とそのリソースにつけられた名前への位置を記録）
 リソース名リスト（リソースデータに対して名前でアクセスする際に利用する名前を記録）

 リソースフォークにアクセスする仕組み 
リソースフォークへのアクセスは「リソースマネージャ」と呼ばれるプログラムを介して行う。
 リソースフォークにアクセスされると、ヘッダからリソースデータおよびリソースマップの開始位置や長さなどを読み込む。
 読み込むべきリソースタイプが指定されると、リソースタイプリストからそのタイプが存在するかのチェックと、そのタイプが含むデータの個数とリソースマップの開始位置から数えたリソース参照リストへのオフセットを調べる。
 リソース参照リストから、リソースID、リソース名へのオフセット、リソースの属性、リソースデータの開始位置から数えたデータのオフセットを調べる。
 指定されたIDあるいは名前のリソースデータが存在したら、先ほど得たオフセットにアクセスし、データ長を調べ、そこに記録された分だけデータを読み込み、戻り値として返す。

 リソースフォークにおけるデータタイプ 
リソースフォークを構成する最小単位のことをデータタイプという。データタイプとは、その名の通りデータの種類 を表すもので、複数種類が存在する。リソースフォークにアクセスした後は、あらかじめ定義しておいたデータタイプ通りに読み込んでいくことで内容を把握できる。データをどのように扱うかはプログラム内部であらかじめ定義しておくことも、TMPLリソースと呼ばれるリソースに記録しておくことも可能である。後者の方法であればResEditなどで見たときにある程度視覚化されるため、後から編集しやすくなる。

 主なデータタイプ 
以下に、主なデータタイプを、アルファベット順に並べ替えて挙げる。
これ以外にも非常に細かくデータタイプが用意されている。

データタイプ（実際の名前）概要BBIT（バイナリビット）真偽値（真か偽か）を1ビットで表す。常に8の倍数個のBBITが必要。BOOL（ブーリアン）真偽値を表す。2バイトで構成され、256が真、0が偽。CHAR（キャラクタ）1バイトの文字を表す。CSTR（Cストリング）C言語の文字列と同じ文字列を表す。DLNG（10進ロングワード整数）10進数のロングワード（4バイト）整数。およそ-21億〜21億までの整数を表す。HEXD（16進数ダンプ）このタイプが現れた位置から末尾までを16進数で表す。コードリソースや圧縮されたデータなどを表す際に用いられる。HLNG（ロングワード16進数）データを4バイト分の16進数値として扱う。C言語でいうunsigned longで21億以上の整数を表した場合などに用いられる。PSTR（Pascalストリング）最初の1バイトに文字列の長さを記録したPascalストリングを表す。TNAM（タイプ名）常に4バイトで構成される、クリエータコードなどを表す文字列（内部的には数値として扱う）。RECT（矩形）矩形の各辺の座標を表す。常に8バイトで構成される。

 主なリソースタイプ 
名前はすべて半角4文字で表される。"snd "や"STR "など、見た目が3文字のリソースタイプ名は、最後に半角スペースを要する。

リソースタイプの名前（実際の名前）概要ALRT（アラート）アプリケーションのアラートボックスの形状を定義するAPPL（アプリケーション）アプリケーションの情報を格納するBNDL（バンドル）アプリケーションで扱えるファイルタイプのアイコンなどを定義するcicn（カラーアイコン）データで利用するカラーアイコンを定義するclut（カラーパレット）データで利用する色を定義するCNTL（コントロール）ウィンドウに配置する部品の詳細を定義するCODE（コードリソース）プログラムの機械語を格納するCURS（カーソル）モノクロのカーソルの形状を定義するDITL（ダイアログアイテムリスト）ウィンドウの部品を定義するDLOG（ダイアログ）アプリケーションのダイアログボックスの形状を定義するFREF（ファイル参照）アプリケーションで扱えるファイルタイプを定義するhfdr（アイコンバルーンヘルプ）Finderで、ファイルにカーソルを重ねた際に表示させるバルーンヘルプの内容や形式の定義icl8（8ビットアイコンリスト）Finderで表示するアイコンを定義するicns（32ビットアイコンリスト）Finderで表示する大型アイコンを定義するICON（アイコン）データで利用するモノクロアイコンを定義するkind（ファイル概要）ファイルタイプの概要を定義するMBAR（メニューバー）アプリケーションのメニューバーとメニューを定義するMDEF（メニュー定義）アプリケーションのメニューを定義する。カラーパレットのような複雑な形状のメニューも定義できるMENU（メニュー）アプリケーションのメニュー項目を定義するMooV（ムービー）QuickTimeムービーを格納するopen（オープン）アプリケーションが開けるファイルタイプを定義するPICT（ピクチャ）ファイルに含まれているPICT画像を格納するPREF（プレファレンス）アプリケーションの環境設定を記録するsnd （サウンド）ファイルで利用するサウンドを格納するSTR （文字列）ファイルで利用する文字列と16進データを格納するSTR#（文字列リスト）ファイルで利用する文字列を複数格納するstyl（スタイル）テキストの書体や文字の色、大きさといったスタイル情報を定義するTEXT（テキスト）テキストを格納するTMPL（テンプレート）リソースデータのフォーマットを定義するvers（バージョン）そのファイルのバージョンや使用する地域を定義するWDEF（ウィンドウ定義）アプリケーションのウィンドウを定義する。不定形ウィンドウなども定義できるWIND（ウィンドウ）アプリケーションのウィンドウの形状を定義する

 主なリソースエディタ 
ResEdit（レスエディット）
Appleが無償で配布している。一般的なリソースデータを視覚的に編集できる。構造がわかれば、さまざまなリソースデータを視覚化できる。
Resorcerer（リソースラ）
高価ながらも、ResEdit以上に多くのリソースデータを視覚的に編集できるため人気は高い。
HexEdit（ヘックスエディット）
一般に言うバイナリエディタで、実際はリソースフォークよりもデータフォークの編集に多く使われる。

 リソースフォークの転送及び保存 
リソースフォークはファイル本体とは別の情報であるため、別のOSに転送したり、HFSやHFS+以外のファイルシステムに保存する場合などは手当てが必要である（これはClassic Mac OSに特有な話といったものではなく、どんなOSの場合でも、ファイル本体とは別になっている情報（たとえばそのファイルの最終変更時刻など、といった情報など）については配慮が必要である）。

リソースフォークを使用している古いClassicアプリケーションを配布したり、サムネイルアイコンの付いた画像を転送するには、MacBinary、BinHex、AppleSingle、AppleDoubleといったフォーマットを用いる必要がある。またこういったフォーマットではほぼ全てがリソースフォークだけではなくFinder情報も扱う。

実際にはアーカイブファイルに纏めたり、ディスクイメージとして配布する方法が浸透した。これらの方法では複数のファイルを1つに纏める事が出来るし、エイリアスも扱う事が出来る。更にデータの圧縮が可能であるという利点もある。

圧縮アーカイブとしては、Compact ProやStuffItが利用された。MacLHAではMacBinaryにしてからLHAアーカイブに格納する手法が取られた。ディスクイメージとしてはIMGフォーマットが利用された。

現在のmacOSでは、Appleがzip形式やtar形式を拡張してリソースフォークやその他のメタデータを保存出来るようにしている。これはAppleDoubleフォーマットを用い、データフォーク (AppleDouble Data file) とそれ以外のメタデータ (AppleDouble Header file) に分けてアーカイブに格納する手法である。また、DMGと呼ばれる新たなディスクイメージも採用している。

 リソースフォークの現状 
インターネットが浸透した現在、ほかのOSのユーザとファイルを共有することが当たり前になってくると、リソースフォークの存在によりほかのOSのユーザを困惑させることがたびたび起こるようになってしまった。そこでmacOSでは、リソースフォークの使用を極力控えることになった。これによりほかのOSでリソースフォークが邪魔することがなくなり、ファイル共有も容易になった。一方で、リソースフォークの代替としてバンドルと呼ばれる、フォルダ階層の中に、リソースフォークにあたるデータをデータフォーク側に格納するようにもした。定型化された情報が多いアプリケーションでとくに多用されている。

こういった改良のおかげでファイル共有が容易になったばかりでなく、リソースフォークのないUNIXのソフトウェアも簡単に移植できるようになった。

macOSではファイルに拡張子を付けることが推奨されているが、プロパティリストを使って、ユーザがなるべく拡張子を意識することがないように工夫されている。