Why is a restored SharePoint folder empty?

Because the files inside were deleted as separate operations from the folder (typically by a sync client), so they are separate entries in the recycle bin. Restoring the folder entry recreates only the folder. Restore the file entries too.

Does restoring a folder in SharePoint restore its contents?

Only the contents that were deleted together with it in the same operation. Items deleted earlier or separately have their own recycle-bin entries and must be restored individually or in bulk.

How do I restore a folder and all its files from the SharePoint recycle bin?

Filter the recycle bin by the folder's original location (the DirName column in PowerShell) and restore every entry under that path, then the folder entry if it is separate.

You restored the folder but it came back empty. Why SharePoint does that, and the fix

Restoring a folder from the recycle bin can recreate the path with nothing inside it. It is not a bug and the files are not lost — they are separate recycle-bin entries. Here is how to get them back together.

You found the folder in the recycle bin, clicked Restore, went back to the library, and there it is: the folder, with its name and its place in the tree, and nothing in it. The files are not lost. They are just not where you expected them to be in the bin.

What actually happened

SharePoint's recycle bin stores operations, not trees. When a user deletes a folder in the browser, SharePoint records one entry for the folder and one for each item that was inside it at that moment, all with the same timestamp, and restoring the folder brings those children back with it.

But the OneDrive sync client, and most scripts, do not delete a folder as one operation. They delete the files first, one by one, then the now-empty folder. Each file becomes its own recycle-bin entry with its own timestamp, a few seconds before the folder's. When you restore only the folder entry, SharePoint restores exactly what that entry contains: an empty folder.

The same thing happens when files were deleted on Monday and the folder on Wednesday.

The fix in the browser

Open the site recycle bin and sort by Original location.
Every entry whose original location starts with the folder's path is one of the missing files.
Select them (100 per page) and Restore. If the folder already exists they land inside it; if not, SharePoint recreates it.

For a big folder this hits the 100-item wall immediately, which is where PowerShell comes in.

The fix in PowerShell

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Finance -Interactive

$path = '/sites/Finance/Shared Documents/2026/Budget'   # the folder's original server-relative path

Get-PnPRecycleBinItem -RowLimit 50000 |
  Where-Object { $_.DirName -like "$path*" } |
  Restore-PnPRecycleBinItem -Force

DirName is the original parent path of each entry, so this catches the files and any subfolders. Restore order does not matter; SharePoint recreates missing parents.

That is the 80% version. The checks that stop it restoring the wrong thing — showing you the list first, skipping files it should not touch, and confirming afterwards — are the part we built the tool for.

One thing to check before you restore

If the folder was restored empty and then someone created new files in it, and you now restore the old ones, you can end up with a mix. That is usually fine. If a filename collides, SharePoint keeps the existing file and the restored one gets a numbered suffix; nothing is overwritten.

Skipping the sort-and-scroll

This is a small problem with a tedious fix, and it is exactly the shape of thing a recycle-bin search tool is for: type the folder path, see every entry under it across both recycle bins, restore them as one job. Undelete365's search is free and shows the same view a site collection admin gets, including other people's deletions.