An inactive WordPress plugin is less exposed than an active one, but it is not gone. Its files stay on the server and its data stays in the database. The hardening guidance is to delete plugins you do not use. Take a backup first, then remove them properly.
Deactivate, delete and uninstall differ
WordPress treats these as separate steps. Deactivation turns the plugin off and runs its deactivation hook, which is for tasks like flushing caches or permalinks. It does not remove options or tables.
Deletion removes the files. A plugin counts as uninstalled when it has been deactivated and the user clicks delete in the admin, and that is when an uninstall routine can run to remove options, settings and tables. Plugin authors must write that cleanup, so some leave data behind.
| Action | Files stay | Data stays | Plugin runs |
|---|---|---|---|
| Deactivate | Yes | Yes | No |
| Delete from the dashboard | No | Depends on the plugin | No |
| Delete files only, for example over FTP | No | Yes, uninstall may not run | No |
The WP-CLI delete command removes files without deactivating or uninstalling, which is a detail worth knowing before you script it.
Why leave nothing behind
The hardening guide says: if you are not using a specific plugin, delete it from the system. The reason is practical. Files on disk are code you must keep patched, scan and back up, and code that could be reached directly if it contains a flaw. Reasoning from how web servers work, a file that is present can usually be requested by URL, whether or not WordPress has loaded the plugin. Treat that as a reason to remove, and test your own server rather than assuming.
A safe removal routine
- Back up the database and files.
- Confirm nothing depends on the plugin: shortcodes in content, widgets, theme calls, scheduled tasks.
- Deactivate it on staging and click through the site.
- Delete it from the dashboard so the uninstall routine runs.
- Check for leftover tables and options and remove what is clearly orphaned, with a backup in hand.
- Record the removal and date.
What to do about orphaned data
Leftover tables are mostly a tidiness problem, but they can keep personal data you no longer need. Review them against your data retention rules before you drop anything. Do not guess at table names: confirm with the plugin's documentation.
Make it routine
Add a quarterly review: list inactive plugins across your sites and decide on each. An inactive list that grows every quarter is a sign nobody owns the cleanup. Safeguard can scan a repository for dependency manifests and produce an SBOM, and there is a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are tracked to closure, the same discipline that stops inactive code lingering.
Quick check
Is deactivating enough?
It stops the plugin running, but the files and data remain. Delete plugins you do not need.
Does deleting a plugin remove its database tables?
Only if the plugin includes an uninstall routine that does so. Check afterwards.
Sources
Last reviewed: 19 October 2026.
