Deactivating a plugin stops it running but leaves its files and data in place. Deleting it from wp-admin removes the files and triggers its uninstall routine, which should clear options and tables if the author wrote one. Inactive plugins are still code on your server, so retire what you do not use.
The three states
The Plugin Handbook defines a plugin as uninstalled when a user has deactivated it and then clicks the delete link in the admin. It also contrasts the two hooks. A deactivation hook is for things like flushing cache or permalinks. The uninstall hook is for removing options and database tables.
| Action | Files on disk | Options and tables |
|---|---|---|
| Deactivate | Stay | Stay |
| Delete from wp-admin | Removed | Removed only if the plugin has uninstall code |
| Delete files by FTP or script | Removed | Stay, because the uninstall routine does not run |
That last row matters. If you remove a plugin folder by hand, its data can linger, and the handbook describes the uninstall routine as the place cleanup happens.
Why this is a supply chain issue
Every installed plugin is something you must keep updated and watch for advisories. An inactive plugin is not running through WordPress, but its files are present, so keep it in your inventory until it is gone. The WP-CLI list command shows inactive plugins, and a delete command can remove them, with an exclude option to protect ones you want to keep.
wp plugin list --status=inactive --field=name
wp plugin delete hello
The handbook example for deleting all inactive plugins uses the list command as input to the delete command, which is quick but worth running on staging first.
A retirement checklist
- Confirm the plugin is truly unused. Search the content for its shortcodes or blocks.
- Take a backup of files and database.
- Deactivate on staging and test key pages.
- Delete through wp-admin or WP-CLI so the uninstall routine can run.
- Check for leftover tables or options if the plugin was important, and decide whether to remove them.
- Remove it from the inventory and note the date and reason.
- Tell the client what was removed.
What to watch for
- Plugins that store personal data may leave it behind. Check with the client what should be kept.
- A plugin with no uninstall code leaves its data by design. That is the author's choice, so read before deleting.
- Dependencies can block deletion. From WordPress 6.5, a plugin that others depend on cannot be deleted while those dependents are installed.
See also our post on the Requires Plugins header.
Example
A client stops using a booking plugin. Someone deactivates it in the admin and moves on. A year later an advisory names that plugin, and the site is flagged by a scan because the files are still present. The cheaper path was to follow the retirement checklist at the time: back up, test, delete through WordPress, check leftovers, and update the inventory. The extra ten minutes avoids a later scramble and a confusing conversation about a plugin nobody remembers installing.
Quick check
Is an inactive plugin a risk?
Its files remain on the server, so it should be in your inventory and removed if unused.
Why delete in wp-admin and not by FTP?
Deleting through WordPress lets the plugin's uninstall routine run, which clears its options and tables if written.
Sources
- Uninstall Methods, Plugin Handbook
- wp plugin delete, WP-CLI handbook
- wp plugin list, WP-CLI handbook
- Introducing Plugin Dependencies in WordPress 6.5
Last reviewed: 19 October 2026.
