by
Lincoln Tracy
1 (0 reviews)
Media Mage
Find duplicate and unused media, check every reference before deleting, and send removals to the trash so a mistake stays reversible.
Media Mage ranks #61,608 among WordPress.org plugins with 1+ active installations, a 1/5 rating from 0 reviews, and was last updated Aug 31, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1
v1.0.0
Current Version v1.0.0
Updated 3 weeks ago
Last Update on 31 Aug, 2026
Refreshed 8 hours ago
Last Refreshed on
Actively maintained
Rank
#61,608
—
No change
Active Installs
1+
-1%
KW Avg Position
N/A
—
No change
Downloads
107
+1 today
Support Resolved
0%
—
No change
Rating
20%
Review 1 out of 5
1
(0 reviews)
Next Milestone 10
0+
10+
60,662
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 8 more installs to reach 10+
Rank Changes
Current
#61,608
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
1.0
0 reviews
Overall
20%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.0.0
- Last Updated
- Aug 31, 2026
- Requires WP
- 5.5+
- Tested Up To
- 7.1
- PHP Version
- 7.4 or higher
- Author
- Lincoln Tracy
Support & Rating
- Rating
- ★ ☆ ☆ ☆ ☆ 1
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade Now
Frequently Asked Questions
Common questions about Media Mage
It is built not to, and the design assumes it will be run on a site nobody has a recent backup of. Deleting unused media moves files to the trash rather than removing them, and every file is re-checked against the whole reference search immediately before it is touched. Resolving a duplicate rewrites every reference to the keeper - full-size URL, every size variant, the -scaled and original siblings, and the JSON-escaped forms - before the duplicate is removed. Take a backup anyway. Any tool that can delete media can delete the wrong media.
References that live in code rather than in the database. Theme PHP, plugin PHP, child-theme templates, and anything served through a CDN URL that does not match what is stored. Media Mage cannot see those and does not pretend to. Read the unused list before acting on it.
Comfortably up to a couple of thousand attachments in the browser. Past that, use WP-CLI. The honest version: finding duplicates is cheap and scales linearly. Finding unused media is not. Every attachment is checked against post content, post meta, term/user/comment meta, options and comments, and those are substring searches that no database index can help with. The cost of each check grows with the size of the library, so the total grows faster than the number of files does. Measured on a test fixture (2 KB images, 3,000 posts, 70% of the library referenced), on a developer machine rather than production hardware: 1,000 attachments - about 90 seconds 5,000 attachments - roughly 40 minutes 20,000 attachments - many hours Your numbers will differ, and larger image files make the hashing step slower without affecting the rest. Treat these as the shape of the curve, not a promise. What this means in practice: on a small or medium site, scan from the admin screen. On a large one, run wp media-mage scan from the command line, where there is no request timeout, and then use wp media-mage unused and wp media-mage delete --dry-run to review before acting. Making the unused scan fast on very large libraries is the main thing on the list for the next version.
Add it to the ignore list. Ignored files stay in the media library and stop appearing in the unused results. For anything you want handled in code, the wpmj_is_referenced filter runs last, after every built-in check has come up empty, and receives the attachment ID and every URL path that was checked: add_filter( 'wpmj_is_referenced', function ( $referenced, $att_id, $paths ) { if ( in_array( $att_id, [ 42, 108 ], true ) ) { return true; } return $referenced; }, 10, 3 );
Yes, and this is why the plugin exists. Oxygen stores layouts as base64-encoded post meta and options. Read those values as plain text and no image reference in them is visible, so an Oxygen site looks like it has hundreds of unused images. Media Mage decodes that data and searches inside it, matching on full paths rather than bare filenames so logo.png does not match site-logo.png.
Yes. All four store their data in post content or post meta, where the URL search reaches, including the JSON-escaped slashes that block attributes and JSON meta use. Gutenberg blocks that carry an attachment ID and no URL are matched on the ID and on the wp-image-N class.
They count as referenced. Trash is restorable, and deleting the images out from under a trashed post breaks the restore.
No. Resolving rewrites the references to the keeper and then removes the duplicate for good. The site keeps rendering, because every reference now points at the keeper, but the file is gone. Deleting unused media is the reversible one, up until the trash is emptied.
The hash phase runs 50 attachments per request, the reference phase 25, and hashes are cached against file mtime so a second scan skips the hashing work for anything that has not changed. On a test fixture of 500 attachments across 38 posts, a full first scan takes roughly 30 to 40 seconds. Larger libraries scale roughly linearly.
Yes. Every operation the admin screen performs is available under wp media-mage: wp media-mage scan wp media-mage duplicates --format=json wp media-mage unused wp media-mage where <id> wp media-mage resolve --dry-run wp media-mage delete --dry-run wp media-mage delete --permanent --yes wp media-mage export --file=report.csv wp media-mage ignore add <id>... wp media-mage ignore list wp media-mage trash list wp media-mage trash restore <id>... wp media-mage trash empty --yes resolve and `delete` both take `--dry-run`, which reports exactly what would happen and changes nothing. Use it first.