To delete a theme in WordPress, go to Appearance, Themes, click the theme you want to remove, and choose Delete in the bottom-right corner of the Theme Details window. The button only appears on a theme that is not active, so switch to another theme first if you are removing the one you use.
That removes the theme's folder. It does not remove the theme's settings, which stay in your database and quietly come back if you ever install the same theme again.
Every guide on the first page of results covers the button. None of the ones we read says what the button leaves behind, or what happens when you delete the active theme by FTP instead.
Both are below, checked against the WordPress 7.1.4 source.
How do I delete a theme from the WordPress dashboard?
- Go to Appearance, Themes.
- If the theme you want gone is active, activate a different one first.
- Click the theme's screenshot (or Theme Details) to open its overlay.
- Click Delete at the bottom right, then confirm the browser prompt.
WordPress redirects back with "Theme deleted." There is no bulk delete on a single site, so repeat it per theme.
Why is there no Delete button?
Four reasons, in the order you are likely to hit them.
It is the active theme. The overlay for the active theme has Customize, not Delete. WordPress will not delete the theme the site is running.
It is the parent of your active child theme. Core removes the Delete action from the parent too. If you build the delete URL by hand anyway, WordPress refuses with "You cannot delete a theme while it has an active child theme."
You are on multisite. Individual site admins cannot delete themes at all: on a network, the delete_themes capability belongs to super admins only.
Go to Network Admin, Themes. The Delete link only shows on themes that are not network enabled, so click Network Disable first.
File changes are switched off. If wp-config.php sets DISALLOW_FILE_MODS to true, WordPress denies delete_themes to everyone, the same way it hides plugin and core updates.
Managed hosts sometimes set this. Delete through the host's file manager or WP-CLI instead.
What does deleting a theme actually remove?
Here is what delete_theme() in wp-admin/includes/theme.php does, in order:
- Deletes the folder
wp-content/themes/<slug>/and everything in it. - Deletes that theme's translation files (
.po,.mo,.l10n.phpand the JSON files) fromwp-content/languages/themes/. - On multisite, removes the theme from the network's allowed themes.
- Clears the theme cache and the cached update check.
That is the complete list. It never touches the options table or the posts table.
What does deleting a theme leave in the database?
Two kinds of data survive, and both are keyed by the theme's folder name.
Customizer settings. Classic themes save their settings in a single option called theme_mods_<slug>: menu locations, custom logo, header image, background, colours and whatever extra settings the theme registered.
When you switch away from a theme, WordPress marks that option as not autoloaded, so it stops costing anything on page loads. It is never deleted.
Site Editor changes. Block themes store your edits as posts.
Templates you customised are wp_template posts, edited headers and footers are wp_template_part posts, and your Styles changes are a wp_global_styles post named wp-global-styles-<slug>. Each one is tagged with the theme's slug in a hidden wp_theme taxonomy, which is how WordPress knows they belong to that theme.
Deleting the theme leaves all of them in place.
On top of that, anything the theme created itself (its own options, custom tables, a demo-import's pages and media) stays where the theme put it. Core has no idea it exists.
Is that a problem?
Mostly no. The leftovers are small, and the option is not autoloaded after a switch.
It is useful, in fact.
Reinstall the same theme later and it picks up theme_mods_<slug> and its wp_template posts again, so your menus, logo and template edits reappear.
That is the real answer to "I deleted my theme by accident": reinstall the same version from the same source, and your settings return with it. Only edits made directly to the theme's files are gone, because those lived in the folder.
How do I see what a deleted theme left behind?
With WP-CLI over SSH:
# Customizer settings for every theme, installed or not
wp option list --search='theme_mods_*' --fields=option_name,autoload
# Site Editor posts, with the theme each belongs to
wp db query "SELECT p.ID, p.post_type, p.post_name, t.name AS theme
FROM $(wp db prefix)posts p
JOIN $(wp db prefix)term_relationships tr ON tr.object_id = p.ID
JOIN $(wp db prefix)term_taxonomy tt ON tt.term_taxonomy_id = tr.term_taxonomy_id AND tt.taxonomy = 'wp_theme'
JOIN $(wp db prefix)terms t ON t.term_id = tt.term_id
WHERE p.post_type IN ('wp_template', 'wp_template_part', 'wp_global_styles')"
Any theme_mods_ name or theme value that does not match a folder in wp-content/themes/ is a leftover.
To remove one theme's Customizer settings for good, wp option delete theme_mods_<slug>. To remove its Site Editor posts, wp post delete <ID> --force on the IDs the query returned.
Do that on a copy first if the site matters. These are the only record of those settings, and there is no undo once they are gone.
What happens if I delete the active theme by FTP?
WordPress does not stop you, because it is not involved.
You can delete the active theme's folder over FTP or SFTP, in a host file manager, or with wp theme delete <slug> --force (without --force, WP-CLI refuses with "Can't delete the currently active theme"). The result is the same each time.
Visitors get an empty page. The template loader finds no template file to include, and for a logged-out visitor it prints nothing at all.
Logged-in admins get an error instead: "The theme directory "
WordPress repairs itself the next time someone opens Appearance, Themes. That screen runs validate_current_theme(), which notices the theme is missing and switches the site to the default theme with the notice "The active theme is broken. Reverting to the default theme."
In WordPress 7.1 that default is Twenty Twenty-Five, set by the WP_DEFAULT_THEME constant. If it is not installed, WordPress falls back to the newest core default theme it can find.
Two things follow from that.
The site stays blank for visitors until an admin happens to open the Themes screen. And if you deleted every core default theme, there may be nothing to fall back to.
Should I delete inactive themes?
Yes, with one exception. Inactive themes still get update notices and still sit in a web-reachable folder, so an abandoned one with a vulnerable file is a risk even though it never runs as your theme.
The exception is one default theme.
Site Health's "You should remove inactive themes" check lets you keep, without a warning, your active theme, its parent if it has one, and one core default theme. Anything beyond those three is what it asks you to delete.
If you delete the default theme as well, Site Health says "Have a default theme available" and explains that "Default themes are used by WordPress automatically if anything is wrong with your chosen theme."
That is the fallback from the section above, so keep one. We go through the rest of that screen in our Site Health post.
Do I need to test before deleting a theme?
For a theme that is inactive, has no child theme, and is not the default, no. Delete it on the live site.
The worst case is that you reinstall it, and as above, its settings come back. Testing that on a copy is overkill.
Test first when the theme is part of a chain or a network:
- Removing a parent theme you think nothing uses. On a single site, a child theme that is installed but inactive will show up as broken under Appearance, Themes with "The parent theme is missing."
- Multisite. Network admin only protects the main site's active theme. Before the delete, WordPress warns "This theme may be active on other sites in the network." It does not tell you which ones, and each of those sites goes blank as described above.
- Clearing database leftovers with the queries above, where a wrong ID deletes a template someone still uses.
- Retiring the theme the site runs on, which is really a theme switch. That is its own job, covered in how to test a theme switch.
For those, copy the live site with the SandyWP Cloner.
It packages the database and wp-content, including every installed theme, into a disposable sandbox, and it only reads the live site. Delete the theme on the copy, then open the front end of each subsite and Appearance, Themes on each one.
Every sandbox has WP-CLI available over SSH, so the wp option list and wp db query commands above run as written. There is also a browser File Manager for deleting a theme folder and a Database manager for running the SQL, if you would rather not use a terminal.
If the copy behaves, do the same on live.
If it does not, you found out on a site nobody visits, and you can throw it away.
Theme developers testing an uninstall path can do the same thing on a fresh sandbox, which is what our theme developer page is about.
The short version
- Dashboard: Appearance, Themes, Theme Details, Delete. Not available for the active theme or the parent of an active child.
- Multisite: Network Admin, Themes, Network Disable, then Delete. Site admins cannot do it.
- WP-CLI:
wp theme delete <slug>. It refuses the active theme and its parent unless you add--force, and you should not. - What goes: the theme folder and its translation files.
- What stays:
theme_mods_<slug>, Site Editor templates, template parts and global styles, and anything the theme stored itself. Reinstalling the theme brings the settings back. - Delete the active theme by FTP and visitors see an empty page until an admin opens Appearance, Themes, which reverts the site to the default theme.
- Keep one default theme installed. It is the fallback for the case above.
