Deleted the wrong file? We read the disk before we promise anything.

Recover deleted files from NTFS, FAT32 and exFAT drives, by three routes: your Recycle Bin — including files Explorer can't show you because their index record is gone; a direct read of the drive itself; and the point-in-time copies Windows keeps, which are the only route here that can bring back a file you overwrote rather than deleted. Nothing reaches the list until we've read the blocks it points at. Free, with no file-count cap and no size cap.

Download free What it cannot do
Never writes to the drive it reads Verified after the copy is written No file or size cap
RECYCLE BIN THE DRIVE SHADOW COPIES READ THE BLOCKS not just the record DATA READS BACK → LISTED BLOCKS GONE → NOT LISTED you get the reason instead RESTORE → A DIFFERENT DISK written, read back, hashed, then named the source drive is opened read-only and never written to
01 Three routes

Three places a lost file can still actually be

Different losses leave different traces. Each route answers a different question, and the page tells you which one you are in.

ROUTE 01

Your Recycle Bin — including what Explorer hides

Explorer drives the bin entirely from its index records. If a file's record is missing or damaged, Explorer shows you nothing while the file itself sits there whole. We read the bin directly, so those files are visible and recoverable. Every account's bin on the PC is counted; only your own is opened.

ROUTE 02

A direct read of the drive

For files that were deleted past the bin — shift-delete, a cleared bin, a card or a USB stick. We read the filesystem's own file table on NTFS, FAT32 and exFAT, rebuild the folder each file lived in where its parent chain can be proven, and follow a fragmented file's recorded layout rather than assuming its pieces sit together. You can point a scan at one folder instead of the whole drive.

ROUTE 03

The copies Windows already kept

Windows quietly keeps point-in-time copies of your drive — the same thing behind "Previous Versions". This is the only route here that can return a file you saved over rather than deleted, and what it finds is a complete, intact file rather than something reassembled from free space. It only works if a copy was taken while your file still existed. We only ever read them: we never create, delete or resize one.

02 The evidence gate

Nothing is listed on the strength of a record alone

The difference between a filename and a file.

A filesystem record is a note saying where a file used to be. On modern storage that note routinely outlives the data it describes — which is how recovery tools end up showing you a real name, a real size, a confident green rating, and a file of zeros. So we do not list a file on the strength of its record. We go and read the blocks the record points at, and only what reads back as real data is offered. If we could not read them, you get the reason instead of a row.

What we check before a file reaches the list

Every one of these is a read, not an inference:

The blocks are readable — we open and read them, rather than trusting the record's word that they exist.
They are not blank — an all-zero read is the signature of a drive that has already discarded the data, and it is refused rather than listed.
Nothing else claims them — the drive's own allocation map is checked, for every fragment of a fragmented file rather than inferred from the first.
The record survived intact — NTFS's per-sector write markers are re-checked, so a half-written record is reported rather than decoded as truth.
The layout adds up — a fragmented file's recorded pieces must all fall inside the drive and total exactly what the record claims. Any disagreement voids the whole layout, because a partly-valid one is a corrupt record rather than a smaller file.
The name is honestly reported — where a delete destroyed part of a filename, the page says so instead of inventing the missing character.

Two honest limits on that. We read a large sample of each file, not every byte of a very large one — so a huge file can pass this check and still have a damaged tail. And the check proves the blocks are readable and unclaimed, not that they are the file's original contents. It is a much stronger basis than a record, and it is not a guarantee. That is why the copy is verified again after it is written.

03 The honest gap

On an internal SSD, deleted usually means gone

This is the single most useful thing on this page, and most recovery tools will not tell you.

When you delete a file, Windows tells an SSD to discard the blocks it was using. Once the drive has done that, the data is gone — not hidden, not overwritten later, gone — and no software on earth can read it back. What survives is the filesystem record: the name, the size, the date, the list of blocks. That is why a tool that reads only records can show you a perfect-looking entry, rate it as being in excellent condition, and hand you a file of zeros. It never looked.

Memory cards and USB sticks usually never receive that instruction, which is why they are where this works best. External drives are usually somewhere in between. Drive Health tells you which of your drives is which.

We would rather tell you a file is gone than sell you the hope that it isn't. On an emptied bin on an internal SSD, the honest answer is usually "nothing here" — and being right about that is the whole reason the check exists.

04 Getting it back

The copy is checked after it is written

A copy command returning is what we asked for. The bytes on the far side are the only evidence.

What happens when you press Recover

It lands on a different physical disk — judged on the disk, never the drive letter, because C: and D: are two partitions of one disk on a great many PCs. Writing a recovered file onto the drive you are recovering from can destroy the next file you were going to ask for. If we cannot tell the two disks apart, we refuse rather than guess.
It is written under a temporary name, flushed to the disk itself, then read back and checked against what we read from the source. Only then does it get its real name.
A mismatch keeps the file and says so — it is left in place under a clearly-marked name rather than deleted. We never delete anything, including our own failed writes.
Nothing is ever overwritten — a name collision gets a new name, never a replacement.
The source drive is opened read-only, and we ask Windows what access it actually granted and refuse to continue if any write access came back.
05 Recovery mode

The awkward part: we are software too

If a file matters, the worst thing that can happen to it is something writing over where it used to be. Installing and running an optimizer is exactly that kind of something.

So we went through our own startup line by line and counted 51 separate places this app writes to your PC. Some of them are not small: a background service with sixteen jobs running every three minutes for everybody, an update installer of about a hundred megabytes downloaded when you start it and again every few hours, a folder deleted and rebuilt every single time you open the app. None of that is unusual for this kind of software. All of it is a problem on the one day you are trying to get a file back.

Recovery mode switches all of it off. One button on the Restore Files page restarts the app with the background service, the cleaners, the driver and app scans, updates, sign-in and every self-repair disabled, and only Restore Files available. Nothing on your PC is optimised, cleaned, updated or repaired while that window is open. Close it and start normally and everything comes back — the jobs that were skipped simply run next time. The window keeps a running count of what it has actually stopped, and names each one, so you can watch it work rather than take our word for it.

What recovery mode cannot do

Said plainly, because a promise you rely on and that turns out to be untrue is worse than no promise at all:

Windows keeps writing to your system drive on its own. It records that you launched a program, it indexes, it updates. No application can switch that off from inside itself.
The app unpacks itself into your temporary folder before its first line of code runs, so that has already happened by the time recovery mode can do anything about it. A version you run from a USB stick without installing is the fix, and it is not built yet — the app says so too, rather than implying otherwise.
If the file was on the drive you installed the app onto, that drive was already written to when you installed it. Nothing can undo that.
It still runs with administrator rights, because reading a drive directly needs them. It is a rule the app follows, not a wall around it.

The best order, if a file matters: stop using the drive it was on, start recovery mode, and put the file back on a different physical drive — which is the only thing we allow anyway.

06 What we refuse to ship

We don't scan free space for file signatures

Most tools call this "deep scan". It is a real technique, we have deliberately not built it, and you should know why.

Carving reads raw blocks looking for the shape of a known file format, without consulting the filesystem at all. It is the right tool when the filesystem is destroyed — after a format, on a card that will not mount. It also cannot recover a filename or a folder, because those live in the metadata it deliberately ignores; it returns thousands of numbered files for you to sort out; and it struggles badly with fragmented files, because it has no record of where the pieces went.

Our answer is precision, not volume: name it, place it in its folder, prove its data is really there, or don't list it. Building a second-rate carver alongside that would work against it. And the free tool that already does carving properly is very good. If your drive has been formatted or Windows can no longer read it, use PhotoRec and TestDisk — free, open source, and the right answer for that job. We would rather send you there than waste the hours that matter most.

07 Limits

What this cannot do

Written plainly, because finding out at the wrong moment is the worst possible time.

A drive you formatted
No. A format writes a fresh filesystem, so the records we read are gone. Use PhotoRec.
A drive Windows can't read
No. RAW volumes, lost partitions and "you need to format this disk" are outside this — we only scan drives Windows can still mount and letter. Use TestDisk.
A physically failing drive
No — and please don't try. We read the whole surface, which is the wrong thing to do to dying hardware. Image it first with a tool built for that, or use a recovery service.
RAID, Storage Spaces, dynamic disks
Not supported.
Phones over USB, network drives, NAS
No. These expose files, not blocks — there is no drive for us to read. Check the device's own trash or your server's Previous Versions.
ext4, APFS, HFS+, ReFS
Not supported. NTFS, FAT32 and exFAT only.
Very large NTFS drives
Above roughly 8 TB we cannot load the drive's allocation map, and rather than guess whether a file's blocks are free we refuse them. Expect very little from a scan of a drive that size.
Fragmented files on exFAT
Refused. On exFAT the delete removes what we would need to follow the pieces, so we decline rather than hand you the first fragment and call it your file.
Compressed, sparse or encrypted files
Detected and refused, never approximated.
A preview before you recover
Not yet. You get the name, folder, size, date, detected file type and what we found when we read it — but not a thumbnail.

It also never runs on its own. There is no background recovery engine, it is not part of Boost or any automatic tune-up, and it never deletes anything.

If the file is still there, we'll prove it. If it isn't, we'll say so.

Part of BRUTAL Optimizer. Free, no file-count cap, no size cap, no paywall in front of the Recover button.

Download free See everything it does

Windows 10/11 · 64-bit · Recovering from a drive? Install onto a different one if you can.