If you have been running a WordPress site for a year or more, there is a good chance your media library holds files no page is actually using. Leftover thumbnails, images from deleted posts, assets that changed during a redesign. They accumulate quietly, and most site owners never notice until a backup takes forever or the library becomes hard to navigate.

This guide walks you through what unused media really is, why it happens and how to find it safely before touching a single delete button.

The real cost of a cluttered media library

Unused files take up storage. The downstream effects matter too.

Backups get heavier. Every orphaned file gets backed up along with everything else. Longer backup windows, more storage costs and slower restores mean real maintenance overhead: time you or your client spend recovering rather than building.

The admin slows down. A bloated library does not directly affect front-end performance, but it does slow down media searches and anything that queries the attachment table. On large sites this is measurable.

Content hygiene suffers. Unused media itself will not hurt your rankings. But the habits that create it, no naming conventions, duplicate images with missing alt text, no cleanup process, tend to degrade content quality over time. A fast, findable library is part of how well-run sites stay well-run.

The simple method: find unused media without a plugin

Before reaching for a cleanup tool, it is worth understanding what WordPress shows you natively and where it falls short.

Step 1: filter for unattached media

In the media library (list view), use the Filter by type → Unattached dropdown. This shows attachments with no parent post in the database.

This is a useful starting point. Remember: unattached does not mean unused. Use this filter as a first pass, not a delete list.

Step 2: check whether the file is actually used anywhere

For each candidate, copy its URL from the media details panel and look for it across your content. You are looking for:

• Direct mentions in post or page content
• Block settings (Gutenberg stores image URLs as attributes)
• Theme customizer settings (site logo, background, header)
• Widget content and custom CSS
• Plugin settings (sliders, galleries, etc.)

Run a search in your database tool, or use the block editor’s search function to check whether any content references the file.

Step 3: build a candidate list, and do not delete yet

The safest workflow runs in two passes:

1. Identify — flag potential orphans based on your filter and manual scan.
2. Confirm — verify each candidate is not used somewhere you did not check.
3. Delete — only once you are confident.

Working on a staging copy during the confirmation phase is strongly recommended if you are dealing with more than a handful of files.

What WordPress’s native tools can and cannot do

WordPress’s media library was designed to upload, browse and insert files, not to govern them. That is not a criticism of the WordPress core team; it reflects a deliberate choice of scope. The library does what it was built to do.

What it was not built to do is tell you where a file is actually used across your site.

The unattached filter is a relationship field, not a usage index. It only records whether a file was uploaded from within a specific post’s edit screen. If you upload an image via the media library and then insert it into a post, WordPress does not update that relationship. If you reuse the same image across ten posts, WordPress only remembers the first one. If you delete the parent post, the image becomes “unattached,” even if it is still displayed on three other pages.

There is no native way to check usage across the full site. WordPress stores image references in at least six different places: post content, post meta, theme customizer options, widget data, block attributes and plugin-specific tables. The admin offers no interface to query across all of them. A manual URL search covers only the places you think to check.

Deletion has no safety net. When you delete a media file in WordPress, nothing warns you that it is still in use. The action is immediate and permanent. The file disappears from every post, page or template it appeared on, leaving a broken image in its place.

This is the gap Mediapapa was built to close: not to replace the media library, but to add the usage awareness, the safety layer and the governance tools that WordPress core intentionally kept outside its scope.

The reliable method: scan actual usage

At a certain volume, say 500 or more files, manual checking stops being practical. But even on smaller sites, the native tools leave too many blind spots to delete with confidence.

Option A: use a plugin with unused media detection (recommended)

The key capability to look for is unused media detection backed by a real usage index. WordPress stores image references in many places beyond post_content: custom field values, serialized option rows, theme customizer settings, page builder block attributes and more. A media cleaner that only checks post_content will consistently flag files as unused that are actually in use somewhere else.

Mediapapa builds a usage index that covers all of these. It tracks where every file is actually referenced across posts, ACF fields, options and page builders, so when it flags a file as unused, it has verified your entire site, not just the fields WordPress exposes natively. The Library Health dashboard then surfaces recommended actions by priority, so you know where to start.

On top of unused media detection, Mediapapa adds Deletion Warnings: if you attempt to delete a file that is still in use somewhere, it stops you before the deletion executes and shows you exactly where the file is referenced. WordPress has no equivalent, since a native delete is immediate and silent. That safety layer is what makes media cleanup effortless rather than stressful.

Before running any cleanup, take a full backup covering both files and database, use staging if the site is in production, and delete in small batches so you can catch issues early.

Option B: semi-technical approach (database queries)

If you are comfortable with SQL, you can query wp_posts and wp_postmeta to find attachment IDs that do not appear in any post_content or meta value. This gives you a raw candidate list to verify before acting.

Blind spots include serialized data, theme customizer settings stored in options and URLs hardcoded in custom templates. If this feels uncertain, stop here. A plugin with a proper usage index covers more ground with less risk.

Option C: WP-CLI (for large sites)

WP-CLI is the appropriate level of tool for high-volume sites: WooCommerce stores with thousands of product images, news sites and large multisite installs. It lets you run media scans as background processes without browser timeouts.

wp media list --post_status=any --fields=ID,post_title,attachment_url

This is advanced territory, appropriate for agencies and developers managing large client sites.

Once you have your candidate list: how to delete safely

Finding unused media and deleting it are two separate operations that deserve separate care. Once you have a verified candidate list, the next step is a safe batch deletion workflow, covering backups, soft-delete, post-delete checks and server-level orphan files.

That process is covered in full in: How to delete unused media files in WordPress (without breaking your site).

FAQ

Additional reading

• Use image and file attachments — WordPress.org official documentation on how attachments work
• Media Library screen — WordPress.org official reference for the media library interface
• Tracking media usage and Deletion Warnings — how Mediapapa’s usage index and Deletion Warnings work
• Understanding Media Scores in Mediapapa — Media Score and Library Health explained
• Detecting and removing duplicate images — the deduplication workflow in Mediapapa