When a user tells a Windows PC to hibernate, the operating system has to perform a remarkable trick in a matter of seconds: it captures the complete contents of physical memory, compresses it, and writes the result to a single file called hiberfil.sys on the system drive. On a laptop with 16 GB of RAM, that sounds like a job for a 16 GB file, yet the file on disk is usually far smaller. The same mechanism also powers Fast Startup, the default shutdown behavior in Windows 10 and Windows 11. Understanding how hiberfil.sys is created, compressed, and read back explains why the file is the size it is, why hibernation resumes so quickly, and how administrators can tune the feature on systems with plenty of memory but limited disk space. It also clears up the persistent confusion between a memory pagefile, a crash dump, and a hibernation image, three files that all concern memory contents but serve different purposes.
What Hiberfil.Sys Actually Stores During Shutdown
Hiberfil.sys lives in the root of the system volume, hidden and protected, and it is created by the memory manager when hibernation is enabled. Its purpose is to hold a snapshot of all memory pages that the kernel considers non-discardable. That includes the kernel address space, drivers, loaded processes, and the parts of each process working set that must be available at resume.
Not every byte of physical memory has to be written. Free pages, zeroed pages, and pages already backed by files that can be re-read from disk can be skipped. If the system has 16 GB installed but only 11 GB in use at shutdown time, the snapshot starts from the used portion, not the raw capacity. This is the first and most basic source of the size reduction people notice.
Windows also writes metadata into the file: architecture information, memory map descriptors, the state of the CPU and devices as captured by ACPI, and checksums. The file should be thought of as a packaged image of the machine state rather than a raw memory dump, which is why it is readable by specialized tools but useless to a casual viewer. Before the image is written, the kernel also coordinates with every registered driver through power callbacks, asking network adapters, storage controllers, and GPU drivers to save state and quiesce activity, because memory contents alone do not describe what the hardware was doing. A driver that returns the wrong answer here is one of the classic causes of failed hibernates.
Another size factor is how the file is laid out. Pages are grouped by type and written as compressed runs, with a header that describes where each run begins and ends. Because the layout is fixed at creation time and the reservation is generous, shutdown never pauses to reallocate clusters, even on a heavily fragmented mechanical drive.
The Compression Engine Behind the Memory Snapshot
The entire hibernation process is handled by the Windows loader environment and a component often called the resume loader. The kernel hands over a list of pages, and they are compressed on the fly using a fast LZ-family algorithm. In modern versions of Windows this is the XPRESS algorithm family, the same Huffman-enhanced LZ77 foundation used in SMB compression and Compact OS. It was chosen because decompression speed matters more at resume time than squeezing out the very last percentage of ratio. Heavier algorithms such as LZMA or the Zstandard variants could shave off more space but would stretch resume times noticeably, which works against the whole purpose of the feature.
Compression is done in parallel across multiple threads on multi-core systems, and the data is written in large sequential blocks, which is friendly to both SSDs and traditional drives. Typical memory contents compress well because memory holds a lot of repeated structures, zero-filled regions, and padding. Ratios of roughly 2:1 to 3:1 are common for ordinary desktop workloads.
Encryption adds another layer. The hibernation file contents are protected so that secrets in memory, such as decryption keys, cannot be read offline from the file. On systems with Modern Standby and device encryption, hibernation is coordinated with the same protection story.
Because the compressed output is unpredictable in size, the file is preallocated at a generous size so the hibernation writer never has to grow the file mid-operation.
How Windows Picks the Default Hiberfil.Sys Size
The size shown by fsutil behavior query or dir is not the amount of compressed data; it is the reservation Windows picked when hibernation was enabled. For full hibernation, the current default reservation is approximately 40 percent of installed RAM, so a 16 GB machine gets roughly a 6.4 GB file. This figure evolved over the years: older releases of Windows reserved 75 percent, then near 100 percent, before the modern defaults reflected how well memory compresses.
Administrators can tune this directly. Running powercfg with the hibernation size switch, for example powercfg /h /size 50, sets the reservation as a percentage of RAM. The value has to leave enough room for the worst case, because if the compressed snapshot cannot fit, hibernation fails rather than truncating memory.
There is also a smaller kind of file chosen with powercfg /h /type reduced, which shrinks the reservation dramatically. That setting is important enough to deserve its own section.
Users who disable hibernation with powercfg /h off remove the file entirely and reclaim every byte, which is a common cleanup step on small NVMe drives. It is worth noting that the reservation exists even when the user never hibernates; the space is claimed the moment hibernation is enabled. That design choice is what makes hibernation reliable, since the kernel can trust that the destination is contiguous and reserved before it begins compressing; a system that tried to allocate space only at shutdown would risk failure on a nearly full disk at exactly the wrong moment.
Fast Startup and the Reduced Hybrid Image
Fast Startup, formally Hybrid Boot, was introduced with Windows 8 and is still enabled by default. Instead of hibernating every running session, it logs the user off and hibernates only the kernel and driver state. The result is written into the same hiberfil.sys using the same compression pipeline, then read back on the next boot so the kernel resumes rather than initializing from scratch.
Because only session zero is captured, the reduced image is far smaller. Microsoft documentation describes a hiberfil.sys sized around 20 percent of installed memory for systems that keep only Fast Startup, which on a 16 GB machine works out to about 3.2 GB. That is what powercfg /h /type reduced creates, and it is a safe choice when the user wants fast boots but never uses full hibernation. The kernel session contents include the nt executive, the loaded device drivers, and the services running in session zero at logoff time. Services with unusual state, such as database engines in the middle of a transaction flush, can make this image larger or slower than usual, which is why shutdown durations vary so much between machines with identical hardware.
There is also a behavior detail administrators should remember on dual-boot and shared-drive machines: because Fast Startup leaves the NTFS volumes in a hibernated consistent state, mounting the Windows drive read-write from another operating system can return stale directory data. This is not a defect but a feature boundary, and the documented remedy is a full restart, which bypasses the resume path entirely.
The trade-off is practical. Full hibernation lets the machine pick up exactly where it left off, applications open, and consume no battery at all. Fast Startup saves seconds at boot but leaves hardware in a fresh-boot state, which is why hotplug changes, firmware updates, and some dual-boot scenarios can behave oddly, and why streamlining shutdown commands to make a true cold boot remain a standard troubleshooting step.
The numbers that matter for planning disk space on a 16 GB system can be summarized as follows: full hibernation reservation near 40 percent, about 6.4 GB; a custom size between 20 and 100 percent set with powercfg; Fast Startup reduced image near 20 percent, about 3.2 GB.
How Resume Reads the File Back
Resume is the mirror image of hibernation. When firmware hands control to the boot manager, it checks for a hibernated state stored in the boot configuration data. If one exists, control passes to the Windows resume application instead of a normal kernel load.
The resume loader maps the hiberfil.sys blocks back into physical memory, decompressing each block in its final location where possible, verifies checksums, and restores CPU and device state. Because the data is already in large sequential chunks and decompression is fast, resume from hibernation on an SSD with 10 GB of live memory commonly completes in a handful of seconds.
If anything is wrong, such as hardware changes, disk corruption, or a failed checksum, the loader discards the image and performs a normal boot, which is a deliberate and safe fallback. Several hardware events deliberately trigger that path. Swapping a disk to a different machine, changing firmware settings that alter the memory map, or upgrading RAM between shutdown and resume all lead Windows to refuse the image, because restoring a stale description of physical hardware can destabilize the kernel. This is why resume failures after motherboard firmware updates are expected rather than alarming.
The resume path also interacts with memory integrity and BitLocker. If the system volume is encrypted, the unlock key has to be available before the resume code can read hiberfil.sys at all, so resume behaves exactly like a boot that needs pre-boot authentication. Machines with sealed keys in the TPM handle this transparently, and the user only sees the normal lock screen.
Sizing Disk Space for Hibernation on Modern Hardware
For IT administrators, hiberfil.sys sizing interacts with storage strategy. On desktops there is rarely a reason to touch it. On fleets of small-enterprise laptops with 128 GB or 256 GB drives, the default reservation is worth auditing.
With 16 GB of RAM, a full hibernation reservation of about 6.4 GB is a modest 5 percent of a 128 GB drive, and acceptable in most cases. With 32 GB or 64 GB of RAM, the reservation grows large enough that switching to the reduced type, or disabling hibernation on machines where mobile users never hibernate, becomes reasonable. Workstation users who routinely hold 20 GB or more in virtual machines or analysis tools are frequently better off with full hibernation than sleep, since sleep draws power continuously and loses the session entirely after a mains outage or a flat battery. The hiberfil.sys cost is the insurance premium for that continuity.
The safe diagnostics are simple. Run powercfg /availablesleepstates to see whether hibernation is supported, fsutil behavior and dir /ah to confirm the on-disk size, Event Viewer Kernel-Power events to correlate resume failures, and the battery report for drain analysis on standby-capable systems. Together they give a complete picture without touching the file itself.
Practical Takeaways for Troubleshooting and Tuning
Hibernation in Windows is deterministic engineering, not trickery. The 16 GB problem is avoided because only resident memory is captured, because general-purpose memory compresses to roughly a third with a fast LZ algorithm, and because the file is reserved, rather than grown, so shutdown never stalls on disk growth.
When users report slow hibernates or failed resumes, the most useful questions are whether the drive is nearly full, whether a driver is streamlining power states badly, and whether memory use near shutdown is unusually high. Clearing the pagefile before hibernation, a habit some guides still recommend, offers little; the significant lever is simply closing memory-hungry applications.
For image builds on modern hardware, the sensible defaults are clear. Keep Fast Startup reduced images on by default, keep full hibernation where users close their lids and move between locations, and document a standard powercfg command in the build notes so every machine in the fleet ends up with the same, predictable footprint on the solid-state drive. When a build includes sleep study support and Modern Standby, hibernation still earns its place: long idle periods eventually transition into hibernate on most default profiles, at which point the compressed hiberfil.sys quietly takes over the job of keeping the session intact with zero power draw. The result is a shutdown mechanism that has hardly changed in concept in two decades, yet keeps improving with every release.