A quick look at the root of the C drive with hidden files enabled often turns up a file nobody remembers creating, sitting at several gigabytes and refusing to shrink no matter how much other cleanup gets done. That file is hiberfil.sys, and its size is not an accident or a leftover from some forgotten installer. It exists because hibernation, one of the sleep states built into every modern PC, needs somewhere durable to put the entire contents of memory before the hardware powers down, and the amount of space it reserves is tied directly to how much RAM sits inside the machine.
The File Sits Hidden at the Root of the System Drive
Windows marks hiberfil.sys as both a system file and a hidden file, which is why it stays invisible in File Explorer until a user explicitly turns on the option to show protected operating system files. It lives in the root folder of whichever drive holds the active Windows installation, alongside other low level files such as the page file, and it is created automatically the moment hibernation support is enabled rather than only when the feature is actually used for the first time. This early creation is the reason many people discover a multi gigabyte file they never asked for; the space gets reserved in advance so the operating system always has a guaranteed place to write to, even if the drive is nearly full when a hibernation request actually happens. The file also carries the system and read-only attributes simultaneously, which is why ordinary attempts to delete it through File Explorer, even after unhiding it, are quietly blocked by Windows unless hibernation is disabled first through the proper command.
Hibernation Copies the Entire Contents of Working Memory Onto Disk
When a computer hibernates, the kernel does something quite different from an ordinary sleep. Rather than keeping RAM powered and refreshing it in the background, Windows treats the transition as suspend to disk: it walks through every page of physical memory that currently holds meaningful data, from running applications to open documents to loaded drivers, and streams that data into hiberfil.sys before cutting power to the memory modules entirely. Once the write finishes, the machine can drop to essentially the same power draw as a full shutdown, because nothing needs to stay energized anymore. On the next boot, the loader recognizes the hibernation signature in the file, reads the saved image back into RAM, and hands control to the kernel at the exact point where it left off, which is why every window and unsaved change reappears untouched.
This mechanism explains the size directly. A conventional temporary file only needs to hold whatever a single application chooses to write, but hiberfil.sys has to be large enough to hold a snapshot of active memory in the worst case, meaning a heavily loaded system with many browser tabs, virtual machines, or large documents open. If the reserved space were smaller than what is actually in use at the moment of hibernation, the operating system would have nowhere to put the remaining data, and the transition would simply fail.
Windows Calculates the Default Size as a Percentage of Installed RAM
Rather than guessing how much memory will be in use at any given hibernation, Windows takes a simpler and more predictable approach: it reserves a fixed percentage of total installed RAM regardless of how much is actually occupied when the feature gets used. On current versions of Windows 10 and Windows 11, the default full hibernation file is set to 40 percent of physical memory, a considerable reduction compared with older releases. Windows 7, for example, historically reserved as much as 75 percent of RAM by default, which is part of why upgraded machines sometimes carry a disproportionately large hiberfil.sys inherited from that earlier calculation. On a laptop with 32 gigabytes of memory, a 40 percent allocation alone works out to roughly 13 gigabytes of disk space claimed before a single byte of that space actually needs to hold real data.
Full hibernation still has to preserve the entire user session, meaning every open application, document and browser tab, since the whole point of the feature is to resume exactly where the user left off. The reason the reservation nonetheless sits well below 100 percent comes down to two other factors: the data gets compressed before it is written, and in practice a system rarely has every single page of installed RAM filled with genuinely incompressible content at the moment it hibernates, so Microsoft can size the default allocation as a realistic upper bound rather than the full physical capacity. Even so, 40 percent of a large memory configuration is still a sizable chunk of storage, which becomes especially noticeable on laptops that pair generous RAM with a comparatively small solid state drive.
A few concrete examples make the scale easier to picture. A budget laptop with 8 gigabytes of RAM reserves roughly 3.2 gigabytes for hiberfil.sys under the default full configuration, a figure most users barely notice on a 512 gigabyte drive. A workstation with 64 gigabytes installed, increasingly common among developers and creative professionals, reserves closer to 26 gigabytes for the same file, and if that machine happens to run a smaller 256 gigabyte boot drive to keep costs down, that single hidden file alone can account for a tenth of the entire available capacity. Gaming laptops and mobile workstations that ship with 32 or 48 gigabytes of memory paired with a 1 terabyte drive rarely feel the impact, which is exactly why the file tends to surprise people on precisely the systems where fast storage was already the scarcest resource, rather than on machines with generous drives to spare.
Fast Startup Quietly Depends on a Smaller Version of the Same File
Many users who believe they never use hibernation are still relying on hiberfil.sys indirectly through Fast Startup, a feature enabled by default that shortens boot time by combining a full user logoff with a partial hibernation of the kernel session. Instead of a completely cold boot, Windows saves just the kernel and driver state to a reduced version of the hibernation file, then restores that state on the next power on instead of reinitializing the entire operating system from scratch. This reduced file type occupies about 20 percent of installed RAM rather than the 40 percent used by full hibernation support, but it still means the file cannot simply be deleted through normal means, since doing so would break the faster boot behavior that most people never consciously configured in the first place.
Compression Narrows the Footprint but Cannot Remove It Entirely
The data written into hiberfil.sys is not stored as a raw memory dump; Windows compresses the captured pages before committing them to disk, which is one of the reasons the file does not simply equal the full amount of RAM installed in the system. Compression ratios vary depending on what kind of data sits in memory at the moment of hibernation, since already compressed content such as video or image buffers shrinks far less than the more repetitive patterns found in typical application and driver memory. This variability is exactly why Windows reserves space based on a fixed percentage rather than the actual post compression size: the operating system cannot know in advance how compressible a given memory snapshot will turn out to be, so it has to allocate for a reasonably safe upper bound instead of trusting an optimistic estimate that might fail under a worst case workload.
There is also a practical reason the reservation happens up front instead of growing the file dynamically the way a log file might. Writing a hibernation image is one of the last operations the kernel performs before it stops scheduling processes entirely, and at that stage the system cannot afford to discover mid write that the disk has run out of contiguous space or that another application has consumed the room it was counting on. Reserving the full allocation in advance, even though most of it sits empty most of the time, guarantees that the write will not fail partway through because of a storage shortfall that appeared after the hibernation sequence had already begun. This is the same reasoning that leads Windows to size the page file ahead of time rather than expanding it only when memory pressure appears, and it is why both files tend to show up together near the top of any storage analysis tool.
Several Commands Let an Administrator Shrink Resize or Remove the File
Because the file size scales with RAM rather than actual disk usage, it becomes a common target when storage runs low, particularly on machines with smaller solid state drives. Windows exposes this control entirely through the powercfg command line tool run from an elevated prompt, and the available options fall into a few practical categories:
- Setting a custom percentage between 40 and 100 with a command such as powercfg /hibernate /size 50, which trades some resume reliability for reclaimed disk space;
- Switching the file type to reduced with powercfg /hibernate /type reduced, which keeps Fast Startup working while dropping the allocation to about 20 percent of RAM and removing the option to hibernate the full session;
- Disabling hibernation entirely with powercfg /hibernate off, which deletes hiberfil.sys outright but also turns off Fast Startup, since that feature has no independent mechanism of its own.
Each of these commands takes effect immediately after a restart, and reversing any of them with powercfg /hibernate on simply recreates the file at whatever size the current settings dictate. The chosen percentage itself is not stored inside hiberfil.sys but in the system registry, under a key managed by the power configuration subsystem, which is why the file regenerates correctly at the same size even after a clean reinstall of the powercfg policy without requiring the user to remember or re-enter the original value. Anyone considering a smaller allocation should keep in mind that setting the percentage too low can cause hibernation to fail outright if the actual memory in use at that moment does not fit inside the reserved space, so aggressive shrinking suits machines that rarely load their RAM close to capacity far better than workstations that routinely run memory heavy applications.
The Tradeoff Comes Down to Storage Versus Resume Reliability
Ultimately hiberfil.sys is large because the feature it supports has a genuinely demanding job: it has to guarantee, without exception, that whatever was running in memory can be reconstructed exactly after the hardware has been completely powered off. A smaller reservation saves gigabytes that might matter on a cramped drive, but it narrows the safety margin the operating system has if memory usage happens to spike right before the machine hibernates. Understanding that relationship makes the file far less mysterious the next time it shows up near the top of a storage report, and it turns adjusting its size from a blind guess into a deliberate choice between disk space and the guarantee that a hibernating session will always come back exactly as it was left.
The decision also looks different depending on the kind of drive involved. On a mechanical hard drive, the sequential write required to flush memory to hiberfil.sys is relatively forgiving, since spinning platters handle large linear writes efficiently even if the file itself is enormous. On a solid state drive, particularly an entry level model using cheaper flash memory, the picture is slightly different: a large hibernation file consumes space that could otherwise serve as spare capacity the drive controller uses for wear leveling and garbage collection, which is one of the reasons some enthusiasts on constrained SSD setups prefer the reduced file type over full hibernation support. None of this makes the file wasteful in the way a leftover installer cache or a duplicate download folder would be; every gigabyte it claims exists to answer a single, well defined engineering requirement, which is why shrinking it is always a tradeoff rather than a straightforward cleanup task.