HFS+ (Mac OS Extended)
HFS+ ran the Mac for 19 years and is still the right answer for HDD-based external drives in 2026. Apple’s modern APFS performs poorly on spinning disks because copy-on-write fragments aggressively. The catalog file B-tree at the heart of HFS+ has its own dedicated recovery tool (DiskWarrior) that rebuilds it from scratch when corrupted, an approach not possible on APFS. For Time Machine on older Macs and any HDD-based external Mac drive, HFS+ is still the answer.
Apple support · recovery labs
Still used for HDDs
2026 HFS+ state
HFS+ (Hierarchical File System Plus, also called Mac OS Extended) is the journaling file system Apple introduced in 1998 with Mac OS 8.1 and used as the default Mac file system until APFS replaced it in 2017. HFS+ is built around a Catalog File B-tree that stores every file and folder record, supports hard links to directories (a unique feature Time Machine relied on), and was designed for HDD storage. It remains the recommended file system for HDD-based external drives used with Macs in 2026 because APFS performs poorly on spinning disks.
How HFS+ Works
Apple introduced HFS+ on January 19, 1998, with the release of Mac OS 8.1. It was a major upgrade to HFS (the Hierarchical File System from 1985), motivated by HFS’s increasingly painful limitations: 16-bit allocation block addresses meant that on a 1 GB drive a 1-byte file consumed 16 KB of space, the 31-character filename limit was crippling for modern naming, and HFS lacked Unicode support. HFS+ solved all three by going to 32-bit block addresses, 255-character UTF-16 filenames, and adding entire new metadata structures.1
The defining property of HFS+ is the Catalog File: a single B-tree that contains a record for every file and every folder on the volume. When you open a file in macOS, the OS searches the Catalog File for the file’s record by parent folder ID and name, then follows the record’s pointers to find where the data lives on disk. This is conceptually similar to NTFS’s MFT, but the Catalog File is a single B-tree (not a flat record array) and the metadata is more compact.
The five special files
An HFS+ volume has five hidden metadata files (called “special files”) that together define the file system:2
- Catalog File. The B-tree of every file and folder on the volume. The most important structure. 4 KB nodes on Mac OS, 8 KB on Mac OS X. Catalog File corruption is the central HFS+ failure mode.
- Allocation File. A bitmap tracking which allocation blocks are free vs in-use. One bit per block: 0 means free, 1 means allocated. Functionally equivalent to NTFS’s
$Bitmapor exFAT’s Allocation Bitmap. - Extents Overflow File. A B-tree that stores the location of file fragments when a file is too fragmented to fit its location list inside the Catalog File. The Catalog File holds the first eight extents (contiguous regions) for each file fork; if a file has more than eight extents, the rest go in the Extents Overflow File.
- Attributes File. A B-tree added in HFS+ (no equivalent in HFS) that stores extended attributes, Finder metadata, and similar per-file extras. This is where macOS stores the kind of per-file metadata that NTFS keeps in alternate data streams.
- Startup File. Used by older boot methods; modern Macs ignore it. Designed for non-Mac systems that need to boot from an HFS+ volume without HFS+ knowledge.
Volume Header and Alternate Volume Header
Every HFS+ volume starts with a Volume Header at sector 2 (after two reserved boot sectors). The Volume Header records the size of allocation blocks, a timestamp for volume creation, the location of all five special files, and various volume-level metadata. HFS+ keeps an Alternate Volume Header at the second-to-last sector of the volume, providing a backup copy that recovery tools can use when the primary Volume Header is damaged.3
The Alternate Volume Header is HFS+’s primary recovery resource at the volume level. The same redundancy approach FAT32 uses with its backup boot sector and exFAT uses with its Backup Boot Region.
Cluster chains via extents
HFS+ tracks file location through extents rather than chained pointers. Each file’s Catalog File record contains an array of extent descriptors: each extent is a starting block number and a length. A file that occupies blocks 1000-1099 is described by a single extent (1000, 100). A fragmented file might have multiple extents (1000, 50), (5000, 30), (8000, 20).
The Catalog File holds up to eight extents per file fork inline. Files with more than eight extents (heavily fragmented files, common on full HDDs) have their additional extents stored in the Extents Overflow File. This is why HFS+ recovery sometimes finds a file’s metadata but only the first eight extents of data: the Extents Overflow File has been damaged and the rest of the file’s locations are lost.
Journaling (added in 2002)
The original HFS+ in 1998 had no journaling; sudden power loss could leave the file system inconsistent. Apple added optional journaling in Mac OS X 10.2.2 (November 2002) and made it default in Mac OS X 10.3 (October 2003). The journal is a circular log that records every metadata transaction before it’s committed to the volume. After a crash, macOS replays the journal on next mount to bring the volume back to a consistent state.4
HFS+ journaling is metadata-only (like NTFS), not full data journaling. The trade-off: protected against file system corruption from crashes, but a file being written when the crash happens may have its data clusters partially written. The Catalog File entry for the file will be consistent (either pre-write or post-write state), but the actual file content might be partial.
Variants of HFS+
Disk Utility shows several HFS+ variants when formatting:
- Mac OS Extended (Journaled). The standard HFS+ format. Journaling enabled by default. The right choice for almost all use cases.
- Mac OS Extended (Journaled, Encrypted). HFS+ with FileVault 2 encryption. Adds whole-volume encryption tied to the user’s password.
- Mac OS Extended (Case-sensitive, Journaled). Filenames are case-sensitive (FILE.txt and file.txt are different files). Used by some development tools that expect Unix-style behavior. The standard variant is case-insensitive but case-preserving (the OS remembers the case but ignores it for matching).
- Mac OS Extended (Case-sensitive, Journaled, Encrypted). Combines case-sensitivity and FileVault 2 encryption.
HFS+ Key Features
HFS+ has a smaller feature set than NTFS or APFS, reflecting its 1998 design era. It does have several Mac-specific features that other file systems lack, and several that became important later when Time Machine and FileVault 2 were built on top.5
Hard links to directories (a Time Machine essential)
HFS+ is unusual among file systems in supporting hard links to directories, not just to files. Most Unix-like file systems (ext4, XFS) refuse to allow directory hard links because they could create cycles in the directory tree. HFS+ allows them carefully and Time Machine relied on this feature heavily.
The reason: pre-APFS Time Machine creates a complete-looking backup of every file in your home folder for each backup point, but uses hard links to make unchanged files share the same on-disk data with previous backups. A 200 GB Time Machine backup can hold 50 hourly backup points where most of the 200 GB is shared via hard links across all of them. APFS replaced this with snapshots; HFS+ Time Machine still works by hard-linking. This is why Time Machine drives needed to be HFS+ before macOS 11 Big Sur: APFS at that point didn’t support hard links to directories, and the Time Machine data layout couldn’t be replicated.6
Resource forks (legacy Mac feature)
HFS+ supports per-file resource forks, a Mac-specific feature dating to the original 1984 Macintosh File System. A resource fork is a second data stream attached to a file, used historically to store icons, dialog boxes, and platform-specific metadata. Modern macOS rarely uses resource forks for new content; they survive mostly for compatibility with legacy applications and for storing extended metadata when files are copied to non-Mac systems.
The recovery implication: a file copied from HFS+ to FAT32 or NTFS may lose its resource fork (or have it stored in a special ._filename companion file if “AppleDouble” mode is used). When recovering files, Mac users sometimes find their applications miss their icons or settings because the resource fork was stripped during a copy operation.
Hot files (HDD performance optimization)
HFS+ tracks small files that are read frequently and migrates them to a “hot zone” near the start of the disk. On HDDs, the start of the disk has the fastest read speeds (the outer tracks of the platter). Frequently-accessed system files end up in the hot zone, reducing seek times for common operations.
This is the opposite of what works well on SSDs (which have uniform access times across the disk and benefit from spreading writes evenly). It’s one of the reasons HFS+ is still preferred for HDDs and APFS replaced it for SSDs.
Compression (added in Snow Leopard)
HFS+ added per-file transparent compression in Mac OS X 10.6 Snow Leopard (2009) using Deflate (Zlib). Later macOS versions added LZVN and LZFSE algorithms. Compressed data is stored in either an extended attribute or the resource fork, depending on size. The compression is mostly used for system files; user data compression is rare and typically achieved through application-level archive formats instead.7
FileVault 2 encryption
Apple added whole-volume encryption to HFS+ as FileVault 2 in Mac OS X 10.7 Lion (2011). FileVault 2 uses XTS-AES-128 encryption with the volume key derived from the user’s password. Unlike APFS where encryption is part of the file system design, FileVault 2 on HFS+ is a layer that sits between the file system and the disk: the entire HFS+ volume is encrypted, and the file system itself doesn’t know the encryption is happening.
The recovery implication: HFS+ FileVault 2 is software encryption that requires only the password or recovery key, unlike T2/Apple Silicon FileVault on APFS which is hardware-bound. With the password or 24-character recovery key, an HFS+ FileVault 2 volume can be decrypted on any Mac, and recovery software can work with the decrypted image.
Other features worth knowing
- Up to 8 EB volumes and files. 32-bit allocation mapping with 64-bit file sizes; no practical limit for consumer storage.
- Up to 4.3 billion files per volume. 32-bit Catalog Node IDs (CNIDs).
- Unicode filenames up to 255 characters. Stored in NFD (Normalization Form D) which decomposes accented characters into base + combining marks.
- Access Control Lists (ACLs). Added in Mac OS X 10.4 Tiger Server. Provides finer-grained permissions than Unix file modes.
- HFSX variant. A case-sensitive variant of HFS+ used in some specific scenarios. Sometimes referred to as HFS+ with case-sensitive option enabled.
HFS+ vs APFS vs NTFS
The three file systems represent three different design eras and three different platforms. Choosing between them depends on which Mac (or Windows machine) you have, what kind of disk you’re using, and whether the drive will be cross-platform.8
| Property | HFS+ | APFS | NTFS |
|---|---|---|---|
| Year introduced | 1998 | 2017 | 1993 |
| Designed for | HDD | SSD / flash | HDD (modernized for SSD) |
| Crash protection | Journaling (since 2002) | Copy-on-write checkpoints | Journaling ($LogFile) |
| Snapshots | No | Native | VSS (limited) |
| Cloning | No | Native (instant) | No |
| Encryption | FileVault 2 (bolted on) | Native | EFS + BitLocker |
| Metadata checksums | No | Yes | No |
| Hard links to directories | Yes (Time Machine) | Limited | No |
| Max file / volume size | 8 EB | 8 EB / 8 EB | 8 PB / 256 TB practical |
| HDD performance | Good (designed for it) | Poor (fragmentation) | Good |
| SSD performance | Adequate | Optimized | Good |
| Cross-platform | Mac (read-only on Win/Linux) | Mac only | Read-only on Mac |
| Time Machine compatibility | All macOS versions | macOS 11+ only | No |
| Best for | Mac HDDs, older Macs | Modern Mac SSDs | Windows internal |
When to use each
Use HFS+ (Mac OS Extended) for: HDD-based external Mac drives (APFS performs poorly on spinning disks); Time Machine drives that need to work with Macs running macOS 10.15 Catalina or earlier; drives shared with Macs running macOS 10.12 Sierra or earlier (which don’t support APFS at all). HFS+ is still the safer compatibility choice when HDD performance matters.
Use APFS for: any modern Mac with an SSD (this happens automatically); SSD-based external drives used only with Macs; Time Machine on macOS 11 Big Sur or later. APFS is the right choice for almost every modern Mac scenario.
Use NTFS for: drives used primarily on Windows. macOS can read NTFS but not write to it natively; Macs need third-party drivers like Paragon NTFS to write.
Use exFAT for: cross-platform external drives shared between Mac and Windows. See the exFAT entry for the trade-offs (no journaling is the main one).
Common HFS+ Corruption Modes
HFS+ corruption almost always traces back to two root causes: the Catalog File B-tree becoming unbalanced or damaged, and the underlying HDD developing bad sectors in critical metadata regions. The journal protects against most crash-induced corruption, but slow disk degradation can cause damage that journaling can’t catch.9
- Catalog File B-tree corruption. The most common HFS+ failure. fsck_hfs reports errors like “Invalid node structure,” “Invalid record count,” “Invalid B-tree node size,” “Keys out of order,” or “Invalid sibling link.” Disk Utility shows “The volume could not be repaired” with exit code 8 and error -69845. The volume may still mount but with files missing or appearing corrupted.
- Volume Header damage. The primary Volume Header at sector 2 is corrupted. Symptoms: macOS can’t mount the volume; Disk Utility reports the disk as unrecognized. The Alternate Volume Header at the second-to-last sector usually still has the correct values; tools like TestDisk and DiskWarrior can copy the backup over the primary.
- Allocation File inconsistency. The bitmap of free vs allocated blocks gets out of sync with reality. Symptoms: free space reported incorrectly, files claiming overlapping blocks, or chkdsk-equivalent fsck_hfs spending excessive time fixing allocation issues.
- Extents Overflow File damage. Files with more than eight extents lose their additional location records. Symptoms: large files recover only partially (the first eight extents worth of data, then truncation). Common on heavily fragmented HDDs with degraded sectors.
- Journal corruption. The journal becomes unreplayable, often because of bad sectors in the journal area. The OS may refuse to mount the volume cleanly. Sometimes solvable by disabling journaling, mounting, then re-enabling.
- Cross-linked files. Two files claim the same allocation blocks, often as a result of failed recovery from earlier corruption. fsck_hfs’s typical fix is to truncate one of the files at the cross-link point, destroying data on the truncated side.
- Bad sectors hitting metadata. Physical bad sectors on the HDD damage Catalog File or Extents Overflow File nodes. Because the special files are stored in specific locations, a bad sector cluster can knock out a critical metadata region. SMART warnings are the upstream signal; address them before the file system becomes unrepairable.
- Improper unmount on FileVault 2 volume. The encrypted volume layer can be left in an inconsistent state. macOS typically recovers automatically on next mount with the password, but failure during automatic recovery requires manual intervention with fsck_hfs and the recovery key.
- Accidental volume erase. “Erase” in Disk Utility creates a fresh empty Catalog File and Volume Header, but doesn’t overwrite the data clusters or the old Catalog entries elsewhere on the disk. Files are recoverable via deep scan or file carving for a window of time before the new volume’s writes overlap them.
When an HFS+ volume has problems, macOS prompts to run First Aid. On minor inconsistencies this is fine. On significant Catalog File damage, fsck_hfs is destructive: its job is to make the file system internally consistent, even if that means truncating files, removing orphaned records, or rebuilding parts of the catalog with whatever data fits. Image the volume first with ddrescue or HDD Raw Copy Tool, then run repairs against the image. If the image-based repair succeeds, you’ve risked nothing on the original; if it fails, the original is still in its starting condition and a recovery lab can work with it.
Warning signs your HFS+ volume is failing
HFS+ is more verbose about errors than APFS, and Console messages plus Disk Utility output usually surface problems clearly. Watch for these in combination:
- Disk Utility First Aid reporting “Invalid node structure,” “Keys out of order,” or “Invalid sibling link.” Catalog File B-tree damage. Stop using the disk and image it before further repair attempts.
- “The volume could not be repaired” with error -69845. Severe Catalog File damage that fsck_hfs can’t fix. Lab-grade tools or DiskWarrior are needed.
- Slow file copies that progressively get slower on an HDD. Often bad sectors being retried by the OS. Stop using the drive and image it.
- Files appearing in Finder but failing to open. Catalog File records are intact but the file’s data clusters are corrupted or unreadable.
- Files showing wrong sizes (often 0 bytes) in Finder. Catalog File metadata damage; the actual data clusters may still be intact and recoverable.
- Filenames showing as garbage characters. Catalog File records have been corrupted. The data is likely still on disk; recovery software finds it through file signatures.
- Time Machine backups failing on an HFS+ Time Machine drive. Often a sign of journal corruption or bad sectors. Critical to address before the drive becomes unrecoverable.
- SMART warnings on the underlying disk. HFS+ corruption is downstream of HDD or SSD failure; the file system can’t survive forever on a deteriorating disk.
When HFS+ Still Matters in 2026
APFS replaced HFS+ as the Mac default in 2017 and most consumer use cases moved to APFS within a few years. But HFS+ persists because APFS isn’t always the right answer. Three scenarios specifically still call for HFS+ in 2026.10
HDD-based external Mac drives
This is the biggest reason HFS+ still matters. APFS performs significantly worse than HFS+ on HDDs over time, because copy-on-write writes new metadata to fresh blocks rather than overwriting in place. On an SSD this is fine: random access has uniform speed. On an HDD, the new blocks end up scattered across the platter, increasing seek times for subsequent reads. After months of use, an APFS HDD can be 2-5x slower than the same drive formatted as HFS+.
For an external HDD that will be used with a Mac, format it as Mac OS Extended (Journaled). The performance difference is significant and grows over time. Apple’s own Disk Utility still includes HFS+ as a format option specifically for HDD use cases.
Time Machine on older Macs
Time Machine has supported APFS as a backup destination since macOS 11 Big Sur (2020). Before that, Time Machine drives had to be HFS+ formatted. If your Time Machine drive needs to back up Macs running macOS 10.15 Catalina or earlier, the drive must be HFS+. An APFS Time Machine drive will not work with those older systems.
This affects more people than you might expect: many businesses and home users still run older Macs that haven’t been upgraded, and the same Time Machine drive often backs up multiple Macs of different vintages. HFS+ Time Machine is universally compatible across every macOS version that supports Time Machine at all.
Macs running macOS Sierra or earlier
APFS shipped with macOS High Sierra (10.13). Earlier macOS versions don’t support APFS at all. If you have a Mac running macOS 10.12 Sierra, 10.11 El Capitan, 10.10 Yosemite, or earlier, the only option for internal and external Mac-formatted drives is HFS+. These older Macs are still in active use in environments where upgrade isn’t possible (legacy software dependencies, audio production setups with discontinued plugins, hardware that lost driver support post-Sierra).
HFS+ advantages and drawbacks
Strengths
- Designed for HDDs; performs better than APFS on spinning disks
- Universal Mac compatibility back to 1998 (Mac OS 8.1)
- Hard links to directories enable Time Machine on older Macs
- Catalog File B-tree has dedicated rebuild tools (DiskWarrior)
- Journaling protects against crash-induced corruption
Trade-offs
- Poor SSD performance compared to APFS
- No native snapshots, cloning, or container/volume sharing
- No metadata checksums; silent corruption is undetectable
- FileVault 2 encryption was bolted on, not designed in
- Read-only on Linux (write support is fragile and not recommended)
HFS+ recovery centers almost entirely on one structure: the Catalog File B-tree. When the Catalog File is intact, recovery is trivial because every file and folder has a record pointing to its data. When the Catalog File is damaged, the volume becomes unmountable and macOS reports the kind of errors that scare users into clicking “Format” or running fsck_hfs in unsafe modes. The HFS+ recovery toolchain is therefore organized around catalog operations, and it’s a fundamentally different approach from APFS or NTFS recovery.11
The legendary tool for HFS+ recovery is DiskWarrior by Alsoft, which takes a unique approach. Instead of trying to repair the existing Catalog File (which is what fsck_hfs does), DiskWarrior rebuilds the entire Catalog File from scratch by reading every node on the volume and reconstructing what the catalog should look like. The rebuilt catalog is verified against the original, and if it’s better (more complete, fewer inconsistencies), DiskWarrior offers to replace the original. This approach works because HFS+’s special files are file-system-level structures that can be regenerated from the actual on-disk state. APFS doesn’t allow this because its B-trees are intertwined with copy-on-write checkpoints; you can’t rebuild an APFS Object Map from the data clusters alone. For severe Catalog File corruption, DiskWarrior succeeds where every other tool fails. Disk Drill for Mac includes an “HFS+ Rebuild Directory” feature that uses a similar approach, and lab-grade tools like UFS Explorer Professional and PC-3000 also support catalog rebuild.12
The single rule that determines HFS+ recovery success: image first, repair second. macOS will offer to run First Aid the moment it sees an HFS+ inconsistency. fsck_hfs is a consistency-repair tool, not a data-recovery tool; on damaged volumes it sometimes truncates files, removes orphaned records, and rebuilds catalog entries with whatever data it has. On a healthy volume with minor inconsistencies, fsck_hfs is fine. On a volume with significant damage, it can make recovery harder by destroying structures that DiskWarrior or specialized tools would have used. Image the volume nondestructively first with ddrescue, HDD Raw Copy Tool, or disk imaging tools; run repair and recovery software against the image, not the original. If the image-based recovery succeeds, you didn’t risk anything on the original. If it fails, the original is still in the same condition it started in, and you can hand it to a lab. The HDD-era design of HFS+ means that the underlying disk is often the real problem, and any additional reads or writes risk pushing it past the point of recovery.
HFS+ FAQ
HFS+ stands for Hierarchical File System Plus. Apple introduced it in January 1998 with Mac OS 8.1 to replace HFS (which dated to 1985). It is also called Mac OS Extended, HFS Plus, or HFS Extended. The improvements over HFS included 32-bit allocation block addresses (for much larger volumes), Unicode filenames up to 255 characters, larger file sizes, and an optional journaling feature added in Mac OS X 10.2.2 in 2002. HFS+ was the default Mac file system from 1998 until macOS High Sierra in 2017, when APFS took over. It remains relevant for HDD-based external drives and older Macs.
The Catalog File is the central data structure of an HFS+ volume. It is a B-tree (balanced tree) that contains a record for every file and every folder on the disk, keyed by the parent folder ID and the item name. When you open a file, macOS searches the Catalog File to find where the file’s data lives on disk. The Catalog File is one of HFS+’s special files (along with the Allocation File, Extents Overflow File, Attributes File, and Startup File) that together define the file system. Catalog File corruption is the single most common HFS+ failure mode, producing errors like ‘Invalid node structure’ or ‘Invalid sibling link.’
HFS+ is the legacy Apple file system from 1998, designed for HDDs. APFS is the modern replacement from 2017, designed for SSDs and flash storage. APFS adds copy-on-write metadata (vs HFS+’s journaling), native snapshots and cloning, integrated FileVault encryption, container/volume sharing, metadata checksums, and nanosecond timestamps. APFS performs significantly faster on SSDs but worse on HDDs because copy-on-write causes fragmentation. For SSD-equipped Macs from High Sierra onward, the system was automatically converted to APFS. HFS+ is still the right choice for HDD-based external Mac drives and for Time Machine compatibility with older Macs.
Yes, in specific scenarios. Use HFS+ (Mac OS Extended) for HDD-based external drives that will be used with Macs, because APFS’s copy-on-write design causes fragmentation that significantly hurts HDD performance over time. Use HFS+ for Time Machine drives that need to work with Macs running macOS 10.15 Catalina or earlier (Time Machine requires HFS+ on those systems). Use HFS+ for compatibility with Macs running macOS 10.12 Sierra or earlier, which do not support APFS at all. For SSD-based external drives, modern Macs, and any new use case, APFS is the better choice.
Yes, often. HFS+ recovery centers on rebuilding the Catalog File B-tree, which is what specialized tools like DiskWarrior do uniquely well. macOS Disk Utility’s First Aid runs fsck_hfs to check and repair logical issues. For severe Catalog File damage, DiskWarrior, Disk Drill (Mac-only), R-Studio, EaseUS Data Recovery Wizard for Mac, and Stellar Data Recovery for Mac can rebuild the catalog from the volume’s actual contents. HFS+ keeps an Alternate Volume Header at the second-to-last sector that helps recovery from primary header damage. The single most important rule: image first with ddrescue or HDD Raw Copy Tool, then run recovery against the image, not the failing disk.
Not natively. Windows has no built-in HFS+ support; you need third-party drivers like HFS+ for Windows by Paragon Software or MacDrive by OWC to read or write HFS+ volumes. Linux can mount HFS+ volumes read-only out of the box on most distributions; read-write support exists but is fragile and not recommended for valuable data because the Linux HFS+ driver is incomplete and can corrupt journaled volumes. For cross-platform external drives shared between Mac and Windows, exFAT is the better choice. For Mac-only HDD external drives, HFS+ is still the right format in 2026.
Related glossary entries
- APFS: HFS+’s modern replacement, optimized for SSDs with snapshots and copy-on-write.
- NTFS: the Windows equivalent; macOS reads NTFS but can’t write to it natively.
- exFAT: the cross-platform choice for external drives shared between Mac and Windows.
- HDD (Hard Disk Drive): the storage technology HFS+ was designed for and where it still performs best.
- Bad Sectors: physical disk failures that drive most HFS+ corruption symptoms.
- Disk Image: image first then recover from the image, the universal HFS+ recovery rule.
- Best Mac data recovery software: software roundup for recovering deleted files from HFS+ volumes.
Sources
- Wikipedia: HFS Plus (accessed April 2026)
- NTFS.com: HFS+ Overview
- Data Recovery Perth: Repair Corrupted HFS File System
- iBoysoft: What is HFS+: exFAT vs HFS+ vs NTFS
- 7 Data Recovery Glossary: HFS+ (Mac OS Extended File System)
- Apple Developer: HFS Plus File System
- Wondershare Recoverit: HFS+ (Mac OS Extended) File System: Everything You Need to Know
- Setapp: APFS, Mac OS Extended (HFS+), exFAT: Differences explained simply
- CleverFiles: How Can I Rebuild a Corrupted HFS+ Catalog Directory?
- OWC: What Is the Best Drive Format? APFS, HFS, NTFS & exFAT Explained
- InsanelyMac: How to Handle HFS/HFS+ Data Recovery
- R-Studio: Data Recovery from an Erased HFS or HFS+ Disk
About the Authors
Data Recovery Fix earns revenue through affiliate links on some product recommendations. This does not influence our reference content. Glossary entries are written and reviewed independently based on documented research, vendor documentation, independent testing, and recovery-engineer review. If anything on this page looks inaccurate, outdated, or worth revisiting, please reach out at contact@datarecoveryfix.com and we’ll review it promptly.
