Is a WordPress revisions plugin needed? Short answer: no, not for most sites. WordPress has stored a full copy of every saved draft and every published edit since version 2.6, with no plugin involved. What a revisions plugin actually adds is a limit on how many pile up, an easier way to clean out old ones, or an approval workflow for a team. If your only question is whether WordPress tracks your edit history, core already does that job. If your question is that your database has thousands of old revisions and you want that under control, that's a different problem, and it has a smaller fix than installing a plugin.
This reflects WordPress core behavior read on 2026-09-18. Menu paths and screen names change between major versions, so if your install looks different from what's described here, check the version number in your dashboard footer first.
What core actually stores, with no plugin installed
Every time you save a draft or update a published post, WordPress writes a complete copy of that version into the database. Open the Settings sidebar on a post, select the Post tab, and click the number next to Revisions to see the list. According to WordPress.org's own documentation on revisions, read 2026-09-18, the revisions screen lets you drag a slider to see exactly what changed between versions, with green for inserted content, red for deleted content, and yellow for changed content, and a Restore button to bring back any version you pick.
Autosaves work differently from revisions. There is only ever one autosave per user for a given post, and a new autosave overwrites the old one rather than adding a row. That's why editing the same paragraph fifty times in one sitting doesn't create fifty database entries; it's one autosave that keeps getting replaced, plus whatever full revisions get saved when you actually click Update or Save Draft.
WordPress 7.0 changed how you view this history. Clicking the revision count now opens a new revisions screen by default, and the older side-by-side classic view is still reachable from a link inside it if you prefer comparing the raw HTML directly. If your site is still on WordPress 6.9 or earlier, you'll see the classic screen automatically, and nothing about the underlying revision data is different, only the interface for looking at it.
Where core genuinely falls short
None of the above is where people start searching for a plugin. The real gaps are these:
No default limit. Unless something has changed it, WordPress keeps every revision of every post forever. A page that gets edited weekly for a few years can accumulate a long list of full-content copies, and none of them get removed automatically.
No bulk cleanup screen. WordPress has an internal function for deleting revisions, but there's no button in wp-admin that says "delete revisions older than X" or "keep only the last 5 across my whole site." You'd need to either accept the accumulation or write the query yourself.
No overview across posts. The revisions screen shows you one post's history at a time. There's no dashboard page listing every post with an unusually long revision list, so the accumulation is invisible until someone measures your database size.
No approval step. Core revisions are a record, not a gate. Anyone who can edit a post can also just click Update on the live version, no review required. Editorial teams that want a "submit for approval" step before a change goes live are asking for something core was never built to do.
Fixing the storage problem without installing anything
If the only issue is accumulation, a single line in wp-config.php handles it. Add define('WP_POST_REVISIONS', 10); and WordPress will keep the ten most recent revisions per post, automatically deleting older ones the next time that post is updated. Per WordPress.org's documentation, the constant accepts three kinds of value: true or -1 stores every revision (the default), false or 0 stores none (autosaves still work), and a positive integer stores that many revisions plus one autosave per user.
Existing accumulated revisions on posts you haven't touched since setting the constant won't be cleaned up retroactively; the limit only applies going forward, when a post is next saved. That's a real limitation of the no-plugin route, and it's the honest reason some sites reach for a cleanup plugin instead of a wp-config edit: a constant prevents future buildup, it doesn't clear a backlog that's already there.
For finer control than a single number, WordPress Developer Resources documents the wp_revisions_to_keep filter, read 2026-09-18, which lets a developer set a different revision limit per post type by hooking a function rather than editing a global constant. That's still not a plugin: it's a few lines in a site-specific plugin or must-use plugin file, and it overrides the WP_POST_REVISIONS value for whichever post type the filter targets.
When a plugin actually earns its place
A dedicated revisions plugin is worth installing when you need one of these, and a constant genuinely can't give it to you:
- A visible list of every post's revision count sitewide, so you can spot and clean an existing backlog without writing SQL.
- Different limits per post type set from a settings screen, if editing
wp-config.phpisn't something you're comfortable doing. - A submit-and-approve workflow, where a contributor's edit to a published page waits for an editor's sign-off before it goes live. That's a genuinely different feature from revision tracking, and only a plugin adds it.
If none of those match your situation, the constant above is the smaller, more reversible fix. It touches one file, does one thing, and doesn't add another plugin's update cycle to your maintenance list.
If you already have a revisions plugin and want it gone
Some revisions plugins only change settings on top of core's existing revision data; removing them leaves your revision history exactly as it was. Others store their own logs or approval history in separate database tables, and what happens next depends on which kind you're running. Before deleting any plugin you're not certain about, it's worth reading through what happens to your content when you delete the plugin that created it, since the outcome ranges from nothing changing to a feature quietly disappearing. If you decide to remove it, the order that lets you back out at every stage is worth following rather than deactivating and deleting in one motion.
Revisions are not a backup, and treating them as one is the actual risk
The most common mistake in this whole area isn't about plugins at all: it's assuming that because WordPress tracks every edit, you don't need a real backup. Revisions live in the same database as the rest of your site. If that database is corrupted, the hosting account is compromised, or a bad migration wipes the tables, your revisions disappear along with everything else, because they were never a separate copy anywhere. Before you make any change you might regret, a five-minute pre-edit routine that includes an actual backup is worth more than any number of stored revisions. A backup you've never checked is a backup you don't actually have, which is why confirming a backup restores cleanly before you need it matters as much as taking the backup in the first place. A stored revision cannot substitute for either step, because it never leaves the database the rest of your site lives in.
So, Is a WordPress Revisions Plugin Needed? The Practical Answer
For most sites, a WordPress revisions plugin is not needed. Core already records every draft and every published edit, shows you what changed, and lets you restore any version with one click. The two problems a plugin solves, unlimited accumulation and no bulk cleanup, are also solvable with a single constant in wp-config.php for most single-author sites. The cases where a plugin genuinely earns its place are narrower than the marketing copy suggests: a sitewide cleanup dashboard, per-type limits without touching code, or a real editorial approval workflow. If none of those describe your site, you likely don't need one, and one fewer plugin is one fewer thing to keep updated.
FAQ
Does WordPress store revisions by default?
Yes. Since WordPress 2.6, every saved draft and every update to a published post creates a full revision automatically, with no setting to turn on and no plugin required.
How many revisions does WordPress keep by default?
Unless WP_POST_REVISIONS is set in wp-config.php, WordPress keeps every revision indefinitely. Setting the constant to a positive number limits future revisions to that count per post; it does not retroactively delete revisions already saved.
Is a WordPress revisions plugin needed for a small, single-author site?
Usually not. A single line in wp-config.php solves the accumulation problem that most small sites actually have. A plugin adds more value on multi-author sites that need an approval workflow, or on older sites that need a bulk cleanup of years of existing revisions.
Do WordPress revisions work as a backup?
No. Revisions live inside the same database as the rest of the site, so anything that damages the database (corruption, a bad migration, a compromised account) takes the revisions with it. A real, separate backup is still necessary regardless of how many revisions are stored.
What happens to revision history if I remove a revisions plugin?
It depends on the plugin. Some only change settings on top of core's own revision data, and removing them leaves the revision history untouched. Others store their own approval logs or history in separate tables, which may remain as orphaned data or disappear depending on the plugin's uninstall routine, so check before deleting one you're unsure about.
