WordPress Autosave: How It Works, How To Recover Work, And When To Change It

Lost work makes autosave feel urgent fast.

Maybe your browser froze. Maybe the tab closed. Maybe you reopened a post and saw content that looked older than the version you swear you had just written. I know that stomach-drop feeling. What matters now is whether WordPress kept a recoverable copy, and how you get it back.

WordPress autosave is the editor’s built-in safety net. It usually saves your current work every 60 seconds while you’re editing, so you can often recover recent changes after a site crash, dropped connection, or accidental tab close. If the whole site changed or disappeared, that is a backup-and-restore problem, not autosave.

TL;DR: Keep autosave on. It protects recent writing, but it doesn’t replace manual saves, WordPress revisions, or full-site backups. Only change the autosave timing when you have a real performance reason. Disabling it is rarely the right first fix. For managed sites, WP Remote backups are the broader safety layer.

What WordPress autosave does

WordPress autosave automatically saves the post or page you’re editing. You don’t have to click Save draft, Update, or Publish for it to run.

The default timing is usually 60 seconds. That means WordPress tries to save changes about once a minute, as long as there are unsaved changes to save.

That timing matters. Autosave doesn’t save every letter as you type it. If you write a paragraph and your laptop dies five seconds later, that paragraph may be gone. If you’ve been working for a few minutes, your chances are much better.

⚠️ Note: Autosave is a recovery feature for the editor. It isn’t a backup of your whole site.

When autosave helps

Autosave is useful when your editing session gets interrupted:

It is less useful when the problem is bigger than the current post. Autosave won’t fix a broken plugin update, a bad theme edit, a deleted media file, or a mistake in wp-config.php, which is the main WordPress configuration file.

That difference is important because the right recovery tool depends on what broke. Autosave helps with recent editor work. Revisions help with older saved versions. Backups help when the site itself needs to be restored.

How WordPress autosave works

WordPress saves autosaves in its database, the storage area behind your posts, pages, and settings. You don’t need to manage those records yourself.

In current WordPress behavior, autosave is careful about published content. The test site had WordPress 6.9.4 installed and ran on PHP 8.3 with MySQL 8.0. For a draft owned by the current user, WordPress updated the draft itself. For a published post, WordPress created a separate autosave revision attached to the post, so unfinished edits did not overwrite the live post.

WordPress also reused the same autosave when we saved again for the same user and post. In plain English: autosave doesn’t create endless new copies every minute. It normally keeps one autosave per user per post.

That should calm one common worry. If your database has hundreds of old versions, revisions are usually the thing to inspect, not autosave.

Recover an autosaved post

Start in the editor for the post or page you were working on. WordPress can only offer recovery when it has a newer autosave or browser backup to compare with the version currently loaded.

🔎 Note: If you don’t see a notice, autosave may still be working. The interval may not have passed, there may have been no unsaved changes, or WordPress may already have saved the same content. If saved versions are missing too, check why WordPress revisions are not showing.

Autosave vs revisions

Autosave and revisions are related, but they solve different problems.

Feature	Best for	How it is created
Autosave	Recovering recent unsaved work	WordPress saves it automatically while you edit
Revisions	Going back to older saved versions	WordPress creates them when you save, update, or publish

Use autosave when something interrupts you before you save. Use revisions when you saved a change earlier and later decide you want an older version back. Here’s the practical version. If your browser crashes while you’re writing, check autosave first. If you rewrote a product page yesterday and regret it today, check revisions.

💡 Note: Manual saves still matter. I save after each meaningful section because that gives me a version I chose, instead of only the latest background save WordPress happened to catch.

What autosave cannot protect

Autosave only protects current editor work. It doesn’t protect the whole WordPress site. Use a different safety layer when one mistake could affect more than the post you’re editing, such as:

This is where full-site backups matter. A backup gives you the files and database needed to put the site back after a problem outside the editor. BlogVault belongs here because it gives you a restore path for site-level mistakes. It doesn’t replace autosave. It covers the problems autosave was never meant to handle.

Change the autosave interval

Most sites should keep the default autosave timing. I would only change it if the editor is slow after you’ve checked the big suspects: the page builder, the browser, and editor-facing plugins. If you do change it, you can set the timing in wp-config.php. Put this line before WordPress’s final “stop editing” comment:

define( 'AUTOSAVE_INTERVAL', 300 );

The number is in seconds. In this example, WordPress autosaves every five minutes.

🛠️ Note: WordPress does not usually give you a simple dashboard setting for autosave timing. If a guide tells you to find it under Settings, check carefully before you follow it.

Should you disable WordPress autosave?

For most site owners, no.

The search phrase disable autosave WordPress makes sense because slow editors are frustrating. But removing autosave is often a rough fix for a problem in another part of the editing stack. Start with the parts most likely to slow the editor: page builders, admin-heavy plugins, and your browser. If the whole dashboard feels slow, diagnose wp-admin lag before blaming autosave.

If WordPress performance is the issue, I would try a longer interval before turning autosave off. If a developer truly needs autosave disabled for a custom editing workflow, that change should live in controlled site code and be tested in staging before it reaches the live site.

Avoid old snippets that set AUTOSAVE_INTERVAL to false. The safer reader-facing choice is a number of seconds, with a clear tradeoff.

If autosave is not showing

When WordPress doesn’t show a recovery option, check the simple causes first:

📌 Note: Page builders may have their own save history. Before editing an important page in a builder, learn where that builder stores drafts, revisions, or undo history.

A safer editing workflow

I wouldn’t rely on one recovery feature for important work. The better habit is unflashy, as safety habits should be:

None of this is exciting. That’s the point. A few ordinary habits give you more recovery paths than one background save ever can.

FAQs

How often does WordPress autosave?

WordPress usually autosaves every 60 seconds while you’re editing and there are unsaved changes. You can change that interval in wp-config.php, but most sites should keep the default.

Where are WordPress autosaves stored?

WordPress stores autosaves in the database. For published posts, autosaves are stored as special revisions attached to the post. For some drafts, WordPress may update the draft itself.

Does autosave overwrite published posts?

No. Autosave should not overwrite the live published post while you’re still editing. WordPress stores unfinished work separately until you choose to update or restore it.

Is autosave the same as revisions?

No. Autosave is automatic recovery for recent unsaved work. Revisions are saved versions created when you save, update, or publish.

Should I disable WordPress autosave?

Usually, no. Keep autosave on unless you have a specific technical reason to change it. If the editor feels slow, troubleshoot the editor first and try a longer interval before disabling recovery.

Conclusion

WordPress autosave is worth keeping on because it protects the exact moment most people worry about: the crash, dropped connection, or closed tab before they clicked save. It’s imperfect, and it won’t catch every last sentence, but it gives you a real chance to recover recent work without turning your writing process into a manual save routine every few seconds.

The smart approach is to use autosave for short-term recovery, revisions for saved version history, and backups for anything that could affect the whole site. If the problem is a hacked or damaged site, use a WordPress hacked recovery guide instead of treating it like an editor recovery issue. Keep those jobs separate and WordPress becomes much less stressful to edit.