Two hidden files, two different jobs
pagefile.sys is the general-purpose backing store: every process's committed memory is guaranteed by RAM plus the pagefile, crash dumps land there after a blue screen, and the Virtual Memory dialog lets you size it, move it or leave it to Windows. swapfile.sys sits next to it in the root of C:\ and shares none of those jobs. It exists for exactly one customer — Store and UWP apps — and takes their memory pages when Windows suspends them in the background.
Why the separation? Store apps live under a different contract: they are expected to suspend and resume at a moment's notice, and entangling that lifecycle with the shared pagefile — and with every other process's memory pressure — would make the scheduler's job miserable. A small dedicated file keeps that traffic isolated, and the isolation is the entire point: swapfile.sys is not extra capacity, it is a private lane.
- pagefile.sys backs committed memory for every process; swapfile.sys pages memory for Store and UWP apps only
- pagefile.sys receives the kernel memory dump after a crash; swapfile.sys has no crash-dump role at all
- pagefile.sys is configurable — size, drive, system-managed — in the Virtual Memory dialog; swapfile.sys has no settings exposure anywhere
- pagefile.sys scales with RAM and load into gigabytes; swapfile.sys stays small, around 256 MB on most machines
- Both are hidden system files in the root of C:\, locked by the system while Windows runs
- Disabling the pagefile makes swapfile.sys disappear too — along with your crash dumps and commit headroom
The trick that makes suspended apps look free
Open Task Manager, launch a Store app, minimize it and come back in ten minutes: its memory number has visibly dropped, yet the app still opens instantly when you click it. That is swapfile.sys at work — Windows wrote the suspended app's pages out to the file, and on resume it pages them straight back. The RAM the app released is real; the cost of bringing it home again is a few hundred megabytes of sequential reads, which is why nobody ever notices the round trip on an SSD.
This also explains the file's modest size: it only ever needs to hold the working sets of suspended Store apps, and even a heavy user rarely keeps more than a few hundred megabytes of those alive at once. If you never run Store apps at all, the file just sits there nearly idle. It does not grow to punish you, and it does not shrink to zero to flatter your free-space counters.
Can you tune it, delete it, move it?
No, no and no. Windows exposes no setting for swapfile.sys — it is absent from the Virtual Memory dialog, it has no supported registry knob, and it cannot be relocated to another drive. It is locked while the system runs, so there is nothing to delete either: pulling it off offline media just makes Windows recreate it at the next boot. The only supported way to make it disappear is to disable the pagefile entirely, a trade that costs you crash dumps and commit headroom to save 256 MB.
If the worry is SSD wear: a file measured in hundreds of megabytes of occasional traffic is a rounding error next to a busy browser cache. Leave both memory files alone and spend the attention on something that pays. And if you genuinely want to dig into the Windows memory machinery, the interesting parts are standby lists and memory compression — not this file.
Questions and Answers
Is it safe to delete swapfile.sys?
Not possible while Windows runs — the file is locked — and pointless offline, because Windows recreates it at the next boot. It is a working part of memory management, not junk.
What is the difference between pagefile.sys and swapfile.sys?
pagefile.sys backs committed memory system-wide and stores crash dumps; swapfile.sys is a small, unconfigurable file that pages memory exclusively for Microsoft Store apps, mostly while they are suspended.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]