I get asked some version of this a lot: “I deactivated the plugin, why is it still doing something?” or the opposite — “I deleted the plugin, is all its data gone now?” The honest answer requires separating three different things WordPress lets a plugin author hook into. Most plugins only implement some of them, which is exactly why the behavior feels inconsistent from one plugin to the next.

Deactivation: register_deactivation_hook

When you click Deactivate, WordPress fires whatever cleanup code the plugin registered with something called register_deactivation_hook() — if the plugin’s developer registered one at all. This hook exists for cleanup that should happen when the plugin stops running, but where the site owner might turn it back on later. Common things it handles:

• Clearing scheduled cron events the plugin created (recurring background tasks, similar to what I cover in my post on how WordPress’s cron system actually works)
• Flushing rewrite rules if the plugin registered custom post types or URL endpoints
• Clearing transients, which are WordPress’s short-lived cached data, so stale cached values don’t linger

What deactivation almost never does is delete the plugin’s actual data — its settings, its custom database tables, any extra data it attached to your posts. That’s by design. Deactivation is meant to be reversible. If deactivating a plugin wiped its settings, nobody would ever feel safe deactivating something just to test for a conflict — which is one of the most common troubleshooting steps in WordPress.

Deletion: uninstall.php or register_uninstall_hook

Full removal only happens if you delete the plugin after deactivating it, and even then, only if the plugin’s developer actually wrote cleanup code for that scenario. There are two mechanisms a plugin can use for this:

• A file literally named uninstall.php in the plugin’s folder, which WordPress runs automatically when you delete the plugin through the admin dashboard
• A callback registered with register_uninstall_hook(), usually set up from the plugin’s main file

If neither of these exists in the plugin’s code, deleting it just removes the plugin’s files. Its settings, its custom database tables, any extra data it added to your posts — all of that stays in your database indefinitely. It’s orphaned, meaning nothing is left to manage or reference it anymore. I’ve inherited sites with a dozen of these ghost tables left behind by plugins that were removed years earlier.

How to actually check for orphaned data

Before touching anything, back up your database first. This is exactly the kind of cleanup where a small typo turns into a real outage.

To find leftover settings, search the wp_options table — the database table WordPress uses to store site-wide settings — for the plugin’s slug or a known settings key. Most plugin authors prefix their option names with something identifiable:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE option_name LIKE '%pluginslug%'
ORDER BY size DESC;

Or, if you’re comfortable with WP-CLI (a command-line tool for managing WordPress), this is quicker:

wp option list --search="pluginslug*"

For custom tables, check what the plugin actually created in your database:

SHOW TABLES LIKE '%pluginslug%';

If you find rows or tables, resist the urge to just delete anything that looks unfamiliar. Some options with generic-looking names are shared infrastructure that other active plugins still depend on. I only remove something once I’ve confirmed which plugin it belonged to, and confirmed that plugin is genuinely gone — not just deactivated for testing.

Why “just deactivate it” isn’t the same as removing it

This distinction matters most in two situations I run into regularly.

First, security audits: a deactivated plugin with a known vulnerability is still sitting on your server’s disk, and some plugins have files that can be reached directly, bypassing the normal WordPress loading process entirely. So deactivation alone isn’t a real fix for a vulnerable plugin. You need to remove it, or better, update it.

Second, performance: I’ve seen sites where a deactivated but not-deleted plugin’s custom table had grown to hundreds of thousands of rows from years of logging. It sat in the database doing nothing except taking up space and slowing down full backups. Deactivating stopped it from writing new rows, but the existing bloat still needed a manual cleanup, and nothing in the WordPress dashboard ever prompts you to do it once the plugin’s own admin screens are gone. That kind of leftover bloat is one of the quieter reasons a slow wp-admin dashboard stays slow even after you think you’ve cleaned house.

If a plugin is genuinely done, my process is: deactivate it, delete it through the admin dashboard (so uninstall.php gets a chance to run if it exists), then manually check wp_options and run SHOW TABLES for anything left behind before calling the removal complete. If you want to test this whole process without risk, doing it on a copy of the site first is worth the extra step — see my notes on setting up a staging site on shared hosting.

Frequently Asked Questions About Plugin Deactivation

If I deactivate a plugin, will I lose all my settings when I turn it back on?

No. Deactivation is specifically designed to be reversible, so a plugin’s settings, custom tables, and data all stay intact in your database. When you reactivate it, everything should be exactly as you left it, assuming the plugin itself is written correctly.

Do I need a developer to check for leftover plugin data?

Not necessarily. If you’re comfortable using a tool like phpMyAdmin (a common web interface for browsing your database that most hosts provide), the queries in this post are copy-paste simple. If that sounds intimidating, this is a reasonable small task to hand to a developer rather than something you need to master yourself.

Is it safe to just delete a plugin I don’t recognize on my site?

Not immediately — figure out what it does and whether anything else on your site depends on it first. Some plugins are dependencies that other plugins or your theme quietly rely on, so deleting an unfamiliar one without checking can break something unrelated.

Will deactivating a plugin fix a security vulnerability in it?

Not fully. The plugin’s files are still sitting on your server, and in some cases they can still be reached directly even while deactivated. If a plugin has a known vulnerability, deleting it (or updating it) is the actual fix — deactivating alone is a partial, temporary measure at best.

How do I know if old plugin data is actually causing a problem?

The clearest sign is a database that keeps growing even though nothing seems to explain why, or a wp-admin dashboard that stays sluggish after you’ve ruled out active plugins as the cause. Checking table sizes and autoloaded option sizes, as described in this post, will usually point you straight at the culprit.

None of this is complicated once you know the three mechanisms involved, but it does require actually checking rather than assuming. WordPress will never tell you on its own that something was left behind.