How to Find and Remove Unused Images in WordPress

To find unused images in WordPress, build a list of candidates and check where each file could be referenced before removing it. Start with a backup and a staging scan, investigate the results, and delete only a reviewed group. Neither the Media Library's Unattached filter nor an automated cleaner can establish every dependency on its own.

An unused-image audit is about use, not resemblance. A completely unique photograph may be unnecessary, while two identical uploads may each have live references. Keep duplicate comparison separate from the decision that a specific attachment can be removed.

Define what unused means for this cleanup

A useful cleanup definition is: no required use has been found within the scope you checked, and the asset is not intentionally being retained. That definition requires an explicit scope. A scan of post content does not cover an external newsletter, a custom template, or next month's campaign plan.

Unattached means the attachment has no recorded parent post. URLs, featured-image fields, or settings can still reference it. When a scanner reports no reference detected, that describes the locations and data formats the scanner checked; it does not establish that the file has no use elsewhere.

An orphaned file has no matching attachment record or recognized relationship, yet a direct URL may still request it, or another processing system may own it. A reserved asset is different again: someone deliberately keeps it for future or occasional use even though no current page displays it.

The WordPress attachment-list query implements the unattached filter through the parent relationship. It is not a website-wide dependency scanner. An attached image can also be absent from the visible content, so attachment status creates both false confidence and unnecessary caution if used as a deletion rule.

Why potentially unused images accumulate

Deleting a post does not necessarily remove every asset uploaded for it. Editors replace featured images, abandon drafts, and keep exports from earlier campaigns. Theme changes can leave old logos or background images in the library after the active design stops requesting them.

Migrations and plugin changes add uncertainty. Imported content can use different IDs or URL forms, a page builder can move its references into another data structure, and a shop can retain images from discontinued products. Repeated uploads create more candidates, but duplication alone does not establish nonuse.

Some apparent clutter is intentional. Seasonal product photographs, press downloads, and assets for scheduled content can have long periods without requests. Ask the content owner before applying a recent-traffic rule to them.

Build a manual candidate list without a plugin

For a small library or one retired campaign, manual review can be more manageable than scanning the entire site. Use the native Media Library to narrow the working set.

Choose a group to investigate, such as images from an abandoned landing page, and identify who can confirm whether it is still needed. Open Media > Library in list view, then use the upload date, file type, or a filename search to find candidates. The full Unattached result set is not a deletion list.

For each candidate, record its attachment ID, main URL, filename, and recognizable subject. Include generated sizes when investigating a directly embedded URL. Inspect relevant content and settings, search for the URL, and check image selections in the owning editors. A developer can also check the appropriate stored IDs and paths.

Mark the asset for retention, further investigation, or approved removal, with the evidence and the person responsible for that decision.

A working record can be as simple as an attachment ID, suspected old campaign, locations checked, unresolved dependencies, and decision. An asset should remain in the review group if the relevant builder data or external uses have not been checked.

Native WordPress does not provide a complete unused-image detector. Dashboard post searches, browser searches, and an inspection of one page are useful evidence within their limits. They cannot prove that an arbitrary attachment is unused throughout the installation.

Check the places where references hide

A reference can be an attachment ID, a full URL, a relative path, a derivative filename, or data from which a URL is generated. This is why a search for one original filename or one numeric ID is incomplete.

Blocks, templates, widgets, and navigation

Inspect Image and Gallery blocks, featured images, synced patterns, and template parts. Include widgets, navigation graphics, the site logo, and the site icon. A picture may belong to a shared layout rather than the post you happen to be viewing.

A frontend crawl complements a database check because it can observe rendered URLs. It also has blind spots: unpublished previews, login-only pages, an unvisited pagination path, or a component that appears after a particular interaction. JavaScript rendering helps only with the states the crawler actually exercises.

Page builders and custom fields

Elementor, Divi, and other builders can store image settings outside ordinary post content. Check that the selected scanner supports your builder and its current data format. Custom plugins can use serialized data, JSON, options, or their own tables.

ACF's Image field documentation illustrates another complication: application code can receive an image array, URL, or ID according to its configured return format. A scanner needs to understand the field and stored reference, not merely search the visible text of a page.

WooCommerce and other dynamic content

Check a shop's main product image, gallery, variation images, and any category or custom-field images it uses. The WooCommerce image and gallery controls are separate from an image inserted into a product description. A hidden or temporarily unavailable product can still need its images.

Dynamic shortcodes, product feeds, REST responses, scripts, and third-party integrations can select media at runtime. An image ID calculated from another record or a URL assembled in code will not necessarily appear as the literal string a scanner expects.

Theme files, CSS backgrounds, and external consumers

Inspect theme settings and custom stylesheets for backgrounds, decorative images, and hardcoded paths. Include generated builder CSS and theme or plugin code where relevant. A database-only search does not inspect an image path present only in a file.

Other websites, newsletters, downloadable documents, and apps can request your public media URLs without storing any reference inside WordPress. Access logs can provide positive evidence that a URL is requested. No requests during a short observation period do not prove that every future or infrequent use has ended.

Use an unused-media plugin as an investigation tool

Media Cleaner documents unused-media scanning and an internal trash system. Its official tutorial separates library checks from uploads-folder and other scan types. Choose the scan for the question you are trying to answer; filesystem leftovers and unused attachment records are different sets.

Check the edition before planning the audit. The tutorial identifies page-builder parsing and uploads-folder scanning as Pro capabilities. A product's broad compatibility description does not establish that the free edition or the installed configuration covers your exact site.

Install and configure Media Cleaner on staging after making a restorable backup. Review the scan settings and supported parsers, starting with the library/content investigation. Deleting files directly from storage bypasses that investigation.

Use a known-used image as a control when you run the scan. Choose one from a builder, product gallery, or custom field that represents the site's dependencies. Review flagged candidates individually, retain evidence of what you checked, and exclude files with known or unresolved uses. Only a small approved selection should enter the recoverable removal stage, followed by site testing before any permanent purge.

The vendor's false-positive guidance directs users to check the Parsers settings and acknowledges that even a listed parser can fail for a particular case. If a known-used image is flagged, resolve that coverage problem before trusting a larger batch.

A scanner can also produce false negatives. Conservative rules may protect attached files or entire attachment families even when individual files are not currently requested. That trade-off can be appropriate for safety; it means the result is not an exact measurement of all reclaimable storage.

Remove only verified candidates, with a recovery path

Before the first removal, define what would count as success: the approved candidates are recoverable, expected pages still render correctly, downloads work, and no required image requests fail. Keep the candidate list outside the cleanup plugin so the record survives its removal.

Back up the whole dependency set, including the database, uploads, relevant theme/plugin files, and any remote object storage. Confirm that the backup can restore an attachment with its original identity, not merely reupload the binary.

Reproduce the environment on staging. Include the active theme, builders, custom fields, product data, and private content needed for the audit. A staging copy without those dependencies cannot validate their media use.

Review the final candidate group. Resolve known uses and ask content owners about scheduled or reserved material. Record why each item can be removed.
Recheck after content changes. A scan can become stale when someone edits a page or selects an image. Pause competing editorial work for the batch, or repeat the relevant reference checks immediately before removal.
Use the installed workflow's recoverable stage. If the cleaner provides temporary trash, move only the approved group there. Understand exactly which records and files it retains and how restoration works.
Test representative routes and states. Check desktop/mobile pages, menus, logos, product variations, galleries, account-only pages, search results, archives, and file downloads as applicable. Inspect actual network requests as well as cached appearances.
Monitor before purging. Review missing-media responses and allow the responsible editors to exercise the affected workflows. Choose the observation period from the site's use patterns rather than an arbitrary universal number of days.
Purge only after acceptance. Keep the external backup and audit record under the site's recovery policy. If a failure appears, stop and restore the affected batch before continuing.

Plugin trash, core Media Trash, and a backup are not interchangeable. WordPress's attachment deletion function documents configuration-dependent trash behavior and permanent file removal. A cleaner's own trash may still consume disk space until it is emptied. It does not protect against a lost database, a damaged server, or every mistake made while changing references.

Do not remove files through SFTP just because a scan called them unused. That can leave attachment records pointing at missing files and bypass the plugin's recovery mechanism. If a site uses offloaded media, investigate its deletion hooks and remote copies before treating a local removal as a complete cleanup.

What to do if an image breaks

Restore it from the cleaner's documented recovery mechanism while that option exists. Otherwise restore the affected files and attachment data from backup, coordinating any database rollback with newer site changes. Check the original failing URL and every associated variant that the page requests.

Then investigate the missed reference and exclude similar cases from the next scan. A successful restore is not evidence that the same detection rule is safe to repeat. Keep a clear record of the unsupported component or data format.

Prevent the next round of clutter

Give uploads an owner and recognizable context. When retiring a campaign or redesigning a section, review its assets as a named collection rather than deleting files based on upload age. Keep an explicit distinction between retired material and assets reserved for later use.

Make reuse easier than uploading again. The WordPress Media Library organization guide explains searchable names, classifications, and a maintainable review queue. After a migration or plugin replacement, revisit the audit's reference coverage before reusing its old exclusions or assumptions.

A central DAM can reduce unmanaged project copies and preserve the context needed to identify a source. Vyso provides collections and user-managed metadata alongside generated descriptions. Its collections documentation describes asset grouping, not website-use detection.

Neither a missing caption nor a DAM duplicate group establishes that WordPress no longer needs an asset. Vyso does not provide a verified WordPress-wide unused-image audit or automatic reference cleanup. Its WordPress plugin remains in development. Keep the usage decision with the tools and people who understand the website's dependencies.

Questions about uncertain cleanup results

Can a crawl prove that the original image is unused?

No. The page may request a generated size instead of the source, and some pages or runtime states may not be crawled. Relate observed URLs to their attachments before drawing a removal conclusion.

Should assets for unpublished drafts be removed?

Not solely because visitors cannot currently see them. Check whether the draft or scheduled content is still planned. Include private and unpublished work in the scope agreed with the content owner.

Will deleting unused images make pages faster?

Removing unneeded files can reduce storage and backup volume. An image that was never requested did not contribute to a visitor's page download. Diagnose delivery performance separately from the storage cleanup.