Is it safe to delete orphaned thumbnails in WordPress?

Not in bulk. A size file can be in use without its original: an old post may carry the thumbnail’s URL in its HTML, and deleting the file breaks that image. Check that the original is really gone and that no content names the file, then check both again at the moment you delete.

Why does WordPress leave thumbnails behind?

WordPress deletes the sizes an image’s metadata lists. Sizes stay behind when the original is removed outside WordPress, over FTP or in a migration; when a plugin removes the library entry but not its files; and when regenerating thumbnails leaves old sizes on disk that the metadata no longer lists.

Orphaned thumbnails in WordPress — the scan said 465, and why you don’t bulk-delete them

Orphaned thumbnails are the image sizes WordPress made for an upload that is no longer there. They take space, no media screen lists them, and they look like the easiest cleanup on the site. A scan of a client’s library reported 465 of them. Every one still had its original.

What an orphaned thumbnail is

Upload photo.jpg and WordPress cuts it into every size the site has registered: photo-150x150.jpg, photo-300x200.jpg and whatever the theme and plugins add. One library entry, one original, a handful of size files beside it. The entry’s metadata lists the sizes, and deleting the image removes them with it.

An orphaned thumbnail is a size file whose original has gone and that no library entry knows about, so nothing in wp-admin will show it to you. It exists only on disk, in wp-content/uploads.

How they come about

Three ways, mostly. A library that has run for ten years has usually seen all three.

The original left another way. Files removed over FTP, or a migration that carried the uploads folder but not the rows that went with it.
A plugin deleted the entry, not the files. It removed the attachment and its original and never looked at the sizes.
The WordPress image sizes changed. A new theme registers new sizes; regenerating thumbnails cuts the new set and rewrites the metadata to list only those. The old files can stay on disk, unlisted, and deleting the image later leaves them behind.

How a scan finds thumbnails without original files

The filename does most of the work. photo-300x200.jpg ends in a size, so its original should be photo.jpg in the same folder, or photo-scaled.jpg or photo-rotated.jpg, the copies WordPress makes of very large and rotated uploads. A size file only counts as orphaned when two tests both fail: there is no file at its stem’s own path, and no library entry names that stem or the file itself.

The second test is there because a size-shaped name can be an original: badge-300x200.png, exported at that size and uploaded as it was, is somebody’s upload, not a thumbnail.

Why you don’t bulk-delete them

Here is where the 465 came from. WordPress keeps a reduced photo-scaled.jpg beside an upload larger than it wants to serve, and regenerating thumbnails can cut a second set of sizes from that copy: photo-scaled-300x200.jpg. Its original is photo-scaled.jpg, sitting right there. The check read every scaled copy as plain photo, so it never found an original called photo-scaled. All 465 were that shape. The plugin is fixed, and the same library now reports none.

That version only listed them, so nothing was lost. But consider what a delete would have done. Not one of the 465 appeared in a post, so a rule of “delete it if no content uses it” would have removed all of them: sizes belonging to photographs that are still on the site. A content check protects you from one mistake. It does nothing about a scan that was wrong about the original.

The other reason is the one content checks exist for. A size file can be in use with no original behind it. An old post can carry photo-300x200.jpg in its HTML from the day an editor inserted it, and the page still shows it. Delete the file and that image breaks, quietly, on a page nobody has opened in years. To delete unused images safely you check two things per file: that the original really is gone, and that no content names the file. Then you check both again at the moment you delete, not against last week’s list.

What Unused Media does about it

Freshet Unused Media decides whether each file in the library is still used; that half is in how to find unused media in WordPress. Sizes with no original sit outside the library, so the scan reports them separately.

Free, the scan ends with a summary: how many it found, how much space they take, how many are used in post content and how many are referenced nowhere. Export CSV downloads every one, with its path, its size, whether post content uses it and which posts do. The free plugin deletes none of them.

Pro adds a table, sortable by size and filtered by referenced or not, and a delete for the ones referenced nowhere; a file post content uses has no checkbox. Each file is checked again just before it goes: still there, still without an original, named by no library entry and no post. If any of that changed, it is skipped and the result says why.

The limits, because they decide what a zero means. “Referenced” means post content and excerpts; a size URL in a theme template or a widget is not seen. The scan reads only folders that still hold a library entry, so a folder emptied of every original is never visited. And with offloaded uploads the section says None found on this server’s disk: a zero about this server, not about your files.

If you would rather clean up the uploads folder by hand, the order is the same: list, check content, check again, then delete. For the files the library does know about, what a media cleaner should find for free is the checklist.