WordPress Post Revisions vs Autosaves: Recover Your Draft Safely

WordPress post revisions vs autosaves can feel confusing when you have just lost a paragraph, overwritten a carefully edited section, or opened a draft that no longer looks the way you remember. WordPress may have an earlier copy of the content, but not every change creates a permanent revision, and not every hosting environment retains the same history.

That distinction is particularly important for a publisher who works with long tutorials, tables, photographs, links, and scheduled posts. Restoring the wrong version may replace valuable newer edits. Restoring an entire website because one paragraph disappeared could be a much bigger mistake. The safest recovery method is the smallest one that solves the actual problem.

This guide explains how WordPress revisions, autosaves, Undo, the Trash, and hosting backups differ. You will learn where to look for an earlier draft, how to compare saved versions, when to copy back one paragraph instead of restoring an entire article, and what to verify after recovery. It also explains why a managed host’s revision limits matter and how the WordPress 7.x revisions interface differs from the older classic screen.

Quick answer: If you just made a mistake in the current editor session, try Undo first. If a browser or connection problem interrupted a draft, look for a newer autosave. If you need content from an earlier manual save or update, inspect Revisions. If a whole post was deleted, check the Trash. Use a site backup only when the problem calls for site-level recovery and the restore risks are understood. None of these options should be assumed to exist until you verify the actual site.

WordPress Post Revisions vs Autosaves: What Is the Difference?

A post revision is a saved historical version of supported post information, usually created when a draft or published post is saved or updated. Its purpose is to let you compare different saved states and, if appropriate, restore content from an earlier state. The revisions feature has to be enabled, and the number of stored versions can be limited by WordPress configuration or hosting policy.

An autosave is a temporary safety copy produced while editing. WordPress uses autosaves to help protect against unexpected interruptions. The official WordPress documentation says there can be at most one autosave per author for a given post: newer autosaves replace that user’s older autosave. Autosave is therefore not an unlimited, minute-by-minute archive of every keystroke.

In many installations the ordinary WordPress autosave interval defaults to about 60 seconds, but this interval can be configured, and offline or browser-side behavior depends on the editor and environment. Do not rely on a promised timer as proof that your very latest sentence was saved. Watch the editor’s saving status and manually save important drafts.

The third option, Undo, belongs to the current editing session. It can reverse a recent action while the editor still knows that action. It generally cannot take you back through an unrelated editing session from yesterday. A hosting backup, by contrast, can include far more than one article and may roll back database entries, media or site changes if restored broadly.

These are not five interchangeable buttons. Start with the smallest recovery tool that addresses your actual problem. WordPress’s official revisions documentation explains the distinction between stored revisions and autosaves, including the fact that autosaves do not overwrite the published post merely by being created.

What Does a WordPress Revision Actually Save?

By default, WordPress tracks changes to core content fields such as the title, author, article content, and excerpt. A revision can therefore be useful when a heading was rewritten, a Custom HTML block lost several paragraphs, or a draft’s text changed between manual saves.

However, an article contains more than text. A real publishing workflow may also include a featured image, image alternative text, categories, tags, SEO-plugin fields, social sharing settings, newsletter options, publishing date, and third-party automations. You should not assume a core post revision is a complete snapshot of all those settings. Plugins can choose to track additional metadata, and some specialized editors manage content differently, but that requires verification on the actual site.

Here is a useful way to think about recovery. An earlier revision may restore the HTML that references three images, but it does not necessarily restore a media file removed from the server. It may recover a previously linked call to action, but it does not prove that a redirect still reaches the correct destination. An old body may contain a disclosure that was later updated; restoring it could bring back outdated language.

For the same reason, revisions are not a replacement for an independent, accessible copy of a high-value article. Keeping an exported HTML source and your image originals gives you another way to inspect and recover the material if the on-site revision list is limited.

Why the Media Library is a separate check

Removing an image block from a post often does not remove the file from the WordPress Media Library. If an article suddenly lacks a photograph, first look for the existing file in Media rather than trying to rewind the entire article. If the media file itself is gone, a revision may still contain its former URL without being able to recreate the missing bytes.

Also check whether the missing image was the featured image or an inline article image. These are different placements. After recovering content, verify both separately and confirm the actual alternative text describes the picture rather than an imagined keyword.

Why one changed paragraph may not justify a full restore

Suppose an article had a useful five-paragraph explanation two days ago. Since then you have corrected several external references and added updated safety guidance. Restoring the entire earlier revision might bring back the desired explanation and discard the newer improvements. A better approach may be to find the paragraph in the older revision, copy it, and paste it into the current draft after checking for contradictions.

That is the central principle of safe post recovery: recover the specific missing material, not automatically everything that surrounded it.

Before You Restore Anything: Four Safety Checks

1. Preserve the best version you still have

If the editor tab is open and contains any unsaved work you want to keep, do not casually refresh or close it. Copy the important text or Custom HTML into a plain-text document first. Saving a temporary local copy is especially sensible if you are about to inspect different revisions or if the browser has been unstable.

Give the local copy an unmistakable name such as article-title-before-revision-review.html. Make sure it contains the content you actually want protected. A file named “backup” is of little value if you never opened it to verify its contents.

2. Identify the correct item and its current status

Check the post title, author, and whether the item is a draft, scheduled post, or already published. Restoring a saved version of an existing public guide is more consequential than fixing an unpublished draft. Do not click Publish, Update, or Restore merely because the editor displays a recovery suggestion.

If you maintain several similar articles, use the actual title and intended permalink to make sure you are working on the right one. A revision from another post will not solve the problem, and an accidental change to a scheduled item can interfere with its planned publishing workflow.

3. Define the part you need back

Write down whether the problem is a missing paragraph, a damaged table, an overwritten full article, an absent image, or a deleted post. The answer determines where to look first. A partial content loss should not automatically trigger a hosting restore.

4. Check whether revision history exists

Open the WordPress settings sidebar and look for a Revisions entry under the Post or Page settings. The count, if present, reflects revisions available to that editor. If you do not see it, there may be no prior saved versions, or revisions may be restricted by site settings or hosting policy.

WordPress core supports revisions, but hosts may change how many are kept. WP Engine’s public platform settings documentation, for example, describes environment-specific revision configuration and a 60-day revision retention period. That is an example of why a universal claim that “WordPress always keeps every past version” is unsafe. Do not change a managed hosting configuration, install a cleanup plugin, or run database commands just to follow an article. First establish what is currently available on your own site.

How to View and Compare WordPress Post Revisions

The following steps use the native WordPress editing experience. The exact revision screen depends on the WordPress version and editor in use. WordPress introduced a newer visual revisions experience in version 7.0; versions 6.9 and earlier use the classic comparison screen. If your site has a different interface or revisions are disabled, follow what the real editor shows rather than forcing a screenshot from another version.

1. Open the intended post. In the WordPress dashboard, go to Posts and choose the exact draft or published article. For a page, use Pages instead.
2. Open Settings. Use the editor’s settings sidebar and select the Post or Page tab, not the settings for an individual block.
3. Locate Revisions. If a count appears next to Revisions, select it. If the entry is absent, do not assume history is hidden behind another random menu; check the missing-revisions troubleshooting section below.
4. Inspect available versions. On the newer revisions screen, select a saved version in the list or move the timeline slider. In the classic screen, use its comparison controls to examine earlier and later versions.
5. Look at the differences, not only the timestamp. Identify the exact wording or blocks that changed. In the newer visual view, additions, deletions, and modifications use distinct indicators. The classic screen can show HTML differences side by side.
6. Decide between partial recovery and full restoration. If you need only one paragraph, copy just that material when the interface allows it. If an entire earlier saved article is the version you deliberately want, consider a full restore after preserving the current state.
7. Verify the result. Follow your editor’s actual restore and save behavior. Review the recovered article in the editor and front-end preview, including its links, images, SEO fields, and publication status, before making any further public publishing action.

WordPress’s current revisions guide documents the new and classic screens. The official WordPress.com guide shows additional examples, including copying only selected content from a historical revision; its account-specific autosave behavior should not be assumed identical on every independently hosted WordPress installation.

What do the colored changes mean?

In the newer WordPress visual revisions screen, added blocks appear green, removed blocks are shown with red indicators, and modified blocks use yellow indicators. These markers are a navigational aid, not proof that the displayed version is the best or most current one. Always read the actual content before you choose Restore.

Can you compare the HTML of a Custom HTML block?

Yes, where the installed revision interface provides a code or classic comparison view. This is particularly useful when a page looks similar but a link target, markup attribute, or paragraph has changed. Look for the relevant code comparison option in the revision screen, or the classic revisions view if supported. Do not assume that a visually unchanged block has identical underlying HTML.

For affiliate publishers, inspect link destinations with care. A previous version might contain a retired offer URL, a missing disclosure, or an incorrect tracked affiliate path. Recovering HTML does not mean every historical link should be republished unchanged.

How to Recover One Paragraph Without Replacing the Whole Article

Partial recovery is often the best response to a small mistake. Imagine you deleted the conclusion from a 3,000-word tutorial, saved the draft, and then added several correct source links. You want the conclusion back, but you want to keep the new links.

1. Make a local copy of the current article first.
2. Open Revisions and locate a version containing the missing conclusion.
3. Read the surrounding context to make sure the passage is still accurate.
4. Where the revision interface supports selecting and copying blocks, copy the relevant block or text without restoring the entire historical version.
5. Return to the current editor and insert the recovered passage in the correct place.
6. Check that the pasted material does not duplicate an existing heading or introduce stale links.
7. Save the draft or approved update as appropriate, then preview the resulting content.

If your version of the editor does not make selective block copying easy, the classic or code comparison may help you identify the passage for careful manual reconstruction. Avoid the risky alternative of restoring a whole article merely to copy one sentence and hoping every later setting survives.

For publishers using a complete Custom HTML block, carefully preserve the opening and closing tags while copying. Moving a paragraph outside its intended container can create broken spacing or malformed layout even when the text itself is correct. Recheck the front-end page, not just the HTML editor.

Recovering an Interrupted Draft From an Autosave

Autosave is most useful when your work was interrupted recently and a newer saved state exists. For example, you are editing a draft, the internet briefly disconnects, and you reopen the post. Depending on the editor and how much work was actually saved, WordPress may offer a notice that a newer autosave is available.

Do not dismiss that notice automatically. Compare the autosaved version with the current displayed content, then choose the version containing the changes you want. The notice may not appear if there is no relevant autosave or if local browser data was lost. It is a recovery opportunity, not a guaranteed archive.

Remember that WordPress generally retains only one autosave per user per post. Subsequent autosaves replace that user’s earlier safety copy. If the editor has been left open after a mistake for a long period, the available autosave may already reflect the newer, unwanted state. For that reason, a manually saved revision or your own source backup can be more reliable when a specific older passage matters.

What if you just deleted a sentence?

Try the editor’s Undo control immediately, before closing or refreshing the tab. Windows editors commonly use Ctrl + Z; on macOS the usual shortcut is Command + Z. The WordPress.com Undo guidance explains why this works for recent editing actions but does not replace a historical revision search.

What if two browser tabs contain different edits?

Stop editing in both tabs. Determine which contains the newer or more complete text and save a local copy of it before refreshing anything. Editing the same post in multiple tabs can create confusion about which copy was last saved or autosaved. This is a preventable problem: keep one editing tab for each post when possible.

What if the browser crashed and no autosave appears?

Do not assume every word is permanently gone, but also do not promise the editor stored it. Check the draft itself, available revisions, and any locally saved article source. If a post has only been edited once and never manually saved, its revision history may be empty. Browser-local recovery behavior differs across environments and may not survive cache clearing, device changes, or private browsing.

What if Revisions Are Missing or Empty?

A missing Revisions row is not automatically a WordPress defect. There may be no earlier version to compare, the site’s revision count may be limited, a host may restrict retention, or the editor may be handling that content differently. Investigate the least risky explanation first.

If a host controls revision settings, ask whether revisions are enabled, how many are retained, and whether there is a time-based deletion policy. Do not insert a copied WP_POST_REVISIONS setting into production configuration merely because an online tutorial suggests it. Host-managed environments can have different defaults and limits, and enabling revisions does not recreate historical versions that were never stored.

A Realistic Publishing Example: Three Images, Links, and a Scheduled Post

Consider a hypothetical long WordPress article with three photographs, an FAQ, two internal links, a table, a featured image, an SEO description, and a future publish date. The writer notices that an earlier, clearer table was accidentally overwritten.

Risky response: Restore an entire site backup from yesterday. That could affect much more than the table, including unrelated posts and site changes made since the backup. Or restore an early article revision without checking whether it also removes newer corrections and links.

Safer response: Preserve today’s article as a local HTML file. Find the older table in post revisions if available. Copy only that table and return it to the current draft. Save the controlled change. Then inspect the rendered table, linked images, SEO settings, article date, and final publishing panel before making the approved change public.

If the entire article body genuinely needs to revert, a full revision restore may be appropriate, but it should still be followed by a deliberate review. A past version of the article is not a complete substitute for checking its current state.

Special caution for scheduled and previously published posts

A scheduled post has a future publication time and often has newsletter or social sharing features enabled. A published post may already have been emailed or shared. Recovery should not become an excuse to reschedule, republish, or resend content without understanding what those systems will do.

After any revision restore or content correction, inspect the actual post status, publication date, public visibility, featured image, email/newsletter controls, and social sharing settings. Different plugin integrations may respond differently to post updates. A WordPress revision does not prove a scheduled social share was sent, nor does it establish that a prior newsletter was delivered.

Our WordPress backup restore test guide explains the larger site-level recovery problem. For planned improvements to an existing published article rather than accident recovery, read our safe content refresh checklist. Those are different tasks from using revision history to recover a missing section.

How to Make Article Recovery Less Stressful Next Time

The best time to protect a long draft is before anything goes wrong. You do not need a new paid plugin to start using a few careful habits:

1. Save meaningful checkpoints. Use the editor’s Save draft or Update controls as appropriate, rather than trusting that every recent keystroke has become a durable history entry.
2. Keep an offline copy for high-value articles. A plain HTML or text version can help recover an exact paragraph even when the host purges older revisions.
3. Label filenames descriptively. Distinguish the source article from exported images and from a later corrected version; avoid a folder of indistinguishable final2 files.
4. Maintain a small asset inventory. Record which three images belong to which article and which one is featured. Recovering the text alone may not rebuild their placements.
5. Check the actual live destinations. A revision is a historical record, not a guarantee that an old affiliate link, resource or legal page still exists.
6. Do not use several editing tabs. Limit accidental autosave conflicts by working on one open editor instance for the same post.
7. Preview before a consequential save. Verify table layout, Custom HTML, headings, image alt text and disclosure before updating an established public page.
8. Keep a separate hosting recovery plan. Post revisions can help with content mistakes; database and server incidents need a different process.

For a publisher producing regular informational content, these simple habits help preserve editorial quality. They do not promise perfect recovery, but they reduce the chances of turning a small mistake into a site-wide emergency.

15-Minute Post-Recovery Quality Checklist

Use this after copying back a paragraph, restoring a revision, or recovering a recent autosave. A complicated site may need a longer review; the timing is only a reasonable starting point for an ordinary article.

1. Confirm the right article: Verify title, slug, and intended post rather than relying on a browser tab name.
2. Read the recovered section: Ensure it is accurate and not duplicated elsewhere in the article.
3. Check HTML structure: Look for broken tags, missing headings, damaged lists, tables or placeholder text.
4. Check images: Confirm inline photographs, featured image and accurate alternative text.
5. Check links: Open important internal resources and approved external destinations; do not restore outdated affiliate tracking.
6. Check disclosures: Verify that any commercial recommendations still include appropriate disclosures and truthful current terms.
7. Check metadata: Review the actual SEO title, description, excerpt, category and other settings rather than assuming revisions handled them.
8. Check publishing state: Confirm draft, scheduled or published status and the intended local date and time.
9. Check integrations: Review any configured newsletter and social sharing choices without triggering duplicate distribution.
10. Preview the front end: Inspect desktop and mobile rendering before considering the recovery complete.

The purpose is not to create bureaucracy around every comma. It is to make sure that recovering one old section did not silently introduce a larger problem elsewhere.

Frequently Asked Questions

Does WordPress save every change as a permanent revision?

No. Autosaves and manually saved revisions behave differently. WordPress generally keeps a maximum of one autosave per user for a given post, while saved revisions depend on configuration and hosting retention. Do not assume there is a permanent version for every minute of editing.

Where do I find Revisions in the block editor?

Open the post or page, show the Settings sidebar, choose the Post or Page tab, and look for the count next to Revisions. WordPress 7.0 and later use a newer visual revision screen; earlier versions use the classic comparison screen. The option may be absent if there is no available saved history or revisions are restricted.

Can I recover only one paragraph from an older WordPress revision?

Often, yes. The newer visual interface can support copying selected blocks from a historical version and returning to the current editor without restoring the entire post. Other installations may require careful copying from a code or classic comparison. Preserve the current content first and check the pasted text after saving.

Will restoring a revision recover my featured image and SEO settings?

Do not assume it will. Core revisions primarily track supported post content fields, while additional metadata may depend on plugins and custom revision support. After recovery, inspect featured images, SEO fields, category, tags, links, schedule and other settings individually.

Are revisions the same as a WordPress backup?

No. A post revision represents earlier saved content for a particular item. A hosting backup may include site files and database content, subject to the backup’s scope. Restoring a whole site can overwrite unrelated work, so reserve that approach for a situation that actually requires it.

Why is an old saved revision missing?

The site may enforce a revision-count limit, a hosting retention period, or disabled history; the old state also might never have been saved. For example, WP Engine documents hosting-related revision policies, including time-based retention. Check your environment’s actual policy instead of assuming WordPress keeps unlimited revisions forever.

Can I recover a post that has been deleted?

First check Posts > Trash or Pages > Trash, as appropriate. A deleted item is a different problem from an older draft revision. If it is no longer in Trash, inspect legitimate backups and other documented recovery options rather than restoring the whole production environment without understanding the consequences.

The Bottom Line: Recover the Smallest Thing That Is Actually Missing

Understanding WordPress post revisions vs autosaves makes a publishing mistake easier to diagnose. Undo is usually the fastest response to a recent editor action. Autosave may help after an interruption. Revisions can recover earlier saved content when the history exists. Trash handles deleted posts. Hosting backups serve wider recovery needs.

Before restoring, preserve what you still have, compare the available versions, and decide whether you need one paragraph or the whole article. Then verify photographs, links, disclosures, metadata, publication status, and the rendered page. That discipline protects readers from stale content and protects the publisher from unnecessarily reversing unrelated work.

A dependable editorial workflow is not one where mistakes never happen. It is one where mistakes can be understood and corrected without sacrificing the improvements made elsewhere.

Official Sources and Further Reading

• WordPress.org — Revisions: revision history, newer and classic comparison interfaces, autosaves and default tracked fields.
• WordPress.com Support — Restore a Revision of a Page or Post: practical visual comparison and selective block recovery; host-specific details may differ.
• WordPress.com Support — Recover a Lost Page or Post: checks for missing drafts, Trash, other content types and autosave notices.
• WordPress.com Support — Undo Your Changes: current-session undo versus revisions and backups.
• WP Engine Support — Platform Settings: examples of managed-hosting revision configuration and retention rules.
• WordPress Developer Documentation — Editing wp-config.php: technical background on autosave and revision configuration for authorized administrators.