Disable WordPress Autosave

In the following simple solution, I cover how to Disable WordPress autosave function. WordPress’s autosave feature is a lifesaver in many cases—it stores your post edits automatically so you don’t lose work if your browser crashes or your internet blips out. But for some site owners, especially when working on long posts, custom post types, or slower servers, autosave can become more of a nuisance than a help. It might trigger too frequently, cause editor lag, or even interfere with certain workflows.

In this guide, I show you how to safely disable or adjust autosave without touching core WordPress files—ensuring your changes survive updates and keep your site secure.

Disable (or Tame) WordPress Autosave

Long ago, we used to edit core files. We don’t edit core files anymore. Use a tiny snippet in your theme or (better) a small must-use plugin. Consider increasing the autosave interval instead of fully disabling it.

Why not edit wp-admin/*.php anymore?

Directly editing core files like post.php or post-new.php will be overwritten on the next update and can cause security and stability issues. WordPress provides hooks to change autosave safely.

Option A: Fully disable autosave (Classic editor)

Recommended delivery: as a tiny must-use plugin so it survives theme changes and updates.

  1. Create a file named disable-autosave.php on your computer with this content:
<?php
/**
 * Plugin Name: Disable Autosave (Classic)
 * Description: Deregisters the classic editor autosave script for all post screens.
 * Author: Lance
 */
add_action( 'admin_print_scripts', function () {
    // Prevent the classic editor autosave script from loading.
    wp_deregister_script( 'autosave' );
} );
  1. Upload it to wp-content/mu-plugins/ (create the folder if it doesn’t exist). MU plugins load automatically.

Scope it to edit screens only? Use this version instead:

<?php
/**
 * Plugin Name: Disable Autosave on Edit Screens
 */
add_action( 'admin_enqueue_scripts', function( $hook ) {
    // Target new/edit post and page screens in wp-admin.
    if ( in_array( $hook, array( 'post.php', 'post-new.php', 'page-new.php' ), true ) ) {
        wp_deregister_script( 'autosave' );
    }
} );

Notes: This targets the classic autosave script. It’s safe and update-proof compared to editing core files. The approach mirrors long-standing community guidance to deregister the autosave script via admin hooks.

Option B: Keep autosave, but slow it down (safer)

If your main issue is frequent saves or server load, increase the interval instead of turning it off:

<?php
// In a site plugin or your (child) theme's functions.php
add_filter( 'autosave_interval', function () {
    return 600; // seconds (10 minutes). Default is typically ~60s.
} );

This uses the documented autosave_interval filter to adjust timing.

Gutenberg / Block Editor considerations

  • The modern block editor has its own autosave logic (including local/REST saves). Fully disabling autosave is not generally recommended because it protects against data loss.
  • You can still increase the autosave interval (filter above applies globally) or use drafts and manual updates for control.

Bonus: Tidy up revisions (reduce database clutter)

Instead of turning revisions off completely, limit how many are kept by adding one of these to wp-config.php (above the line that says “That’s all, stop editing!”):

define( 'WP_POST_REVISIONS', 5 );   // keep last 5 revisions per post
// define( 'WP_POST_REVISIONS', false ); // (not recommended) disable revisions entirely

WordPress officially documents the WP_POST_REVISIONS constant in wp-config.php. Limiting (e.g., 5–10) is a good balance between safety and bloat.

Best practices & cautions

  • Backups still matter. Autosave/revisions are not a substitute for proper backups.
  • Prefer MU plugin over theme functions so changes persist if you switch themes.
  • Test per role/post type if needed (add your own conditionals around the deregistration).

FAQ

Will this break updates?

No—because we’re not editing core files.

Can I disable autosave only for certain post types?

Yes—wrap the deregistration in checks for get_current_screen() and compare $screen->post_type.

<?php
add_action( 'admin_enqueue_scripts', function() {
    $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
    if ( $screen && in_array( $screen->post_type, array( 'post', 'page' ), true ) ) {
        wp_deregister_script( 'autosave' );
    }
} );

Updated: avoids core edits, supports Classic and Block Editor workflows, and favors interval tuning + revision limits for safety.