The draft is written, the block editor shows “Saving…” and the spinner never stops. Or you click Update and the page reloads but the changes are gone. Or the Save button greys out with no error message. Or WordPress throws a “Updating failed” notice with a red border. WordPress post not saving is one of the most alarming editor failures because it looks like content loss — and sometimes it is, if the root cause is not identified quickly. Every failure pattern maps to a specific, fixable cause. For a broader walkthrough, our WordPress Errors Complete Guide is a good next read.
WordPress Post Not Saving — Read the Error First
The most important first step with any WordPress post not saving problem is reading the exact error message before attempting any fix. The block editor displays error notices in a red banner at the top of the screen, and each message points to a different layer of the problem.
“Updating failed. The response is not a valid JSON response” — the server returned HTML (usually an error page or redirect) instead of the JSON the block editor expects. This is almost always a PHP fatal error or a server-side redirect interrupting the REST API save call. “Updating failed. Sorry, you are not allowed to edit this post.” — a permissions problem, either the user’s role lost the capability to edit posts, or the post’s author ownership changed. “Saving failed.” with no further detail — a network interruption, a timeout, or a JavaScript error prevented the save request from completing. Each of these messages has a direct solution path that is distinct from the others — treating them all the same wastes time.
Open the browser developer console (F12 → Console) when the WordPress post not saving error occurs. The console shows the actual HTTP response status for the failed save request. A 401 indicates an authentication issue — the login session expired during a long editing session. A 403 indicates a permission or nonce problem. A 500 indicates a server-side PHP error. A 413 indicates the post content exceeds the server’s post_max_size limit. Each HTTP status code points to the correct fix in the sections below. Our guide on fixing WordPress fatal errors covers the PHP-level errors that produce 500 responses during post save attempts.
Authentication and Nonce Expiry Issues
The most common cause of WordPress post not saving during long editing sessions is an expired authentication nonce. WordPress nonces (security tokens) expire after 12 hours. If you have been editing a post for a very long session — or left the browser open overnight — the nonce embedded in the editor page has expired and the save request is rejected with a 403 error.
The fix for this WordPress post not saving cause is straightforward: reload the editor page. WordPress generates a fresh nonce on each page load. After reloading, the new nonce is valid and saves work correctly. Before reloading, copy the current post content to a text editor as a backup — the reload discards any unsaved changes in the current editor session. After the reload, paste the content back and save immediately.
Prevent nonce expiry — a recurring WordPress post not saving trigger — during long editing sessions by keeping the browser tab active. Modern browsers throttle JavaScript in inactive tabs, which can prevent the block editor’s heartbeat API from refreshing the nonce before it expires. If you regularly write long-form content in single sessions, increase the nonce lifetime by adding to wp-config.php: define('NONCE_LIFE', 86400); — this extends the nonce lifetime to 24 hours. Alternatively, enable the “Autosave interval” setting in the block editor (Settings → General → Autosave interval) to a shorter interval — autosaves refresh the nonce on each successful save. For teams where WordPress post not saving from session expiry is a repeated issue, consider a session management plugin that extends login duration for your specific team’s workflows.
REST API Blocks and Server Configuration
The WordPress block editor saves all posts via the REST API endpoint /wp-json/wp/v2/posts/{id}. When anything blocks this REST API call — a security plugin, a misconfigured server rule, or an invalid WordPress URL setting — WordPress post not saving occurs with a “not a valid JSON response” error because the API call is intercepted before WordPress processes it.
Test the REST API when WordPress post not saving shows a JSON error: navigate to yoursite.com/wp-json/wp/v2/posts in the browser. A JSON array of posts confirms the REST API is accessible. An HTML error page (403, 404, or a security plugin’s block page) confirms the API is being intercepted. Common causes for WordPress post not saving via REST API block: security plugins with restrictions (Wordfence, iThemes Security, Disable REST API plugin), .htaccess rules blocking requests to /wp-json/, and incorrect WordPress URL settings that cause the REST API to redirect rather than respond.
If the REST API returns correctly in the browser but WordPress post not saving persists, the issue may be with the authenticated REST API specifically. Some security plugins allow public REST API access but block authenticated requests for non-administrator roles. Test by temporarily switching the affected user to Administrator and attempting a save — if it saves successfully as Administrator, a role-based REST API restriction is the cause. Check the security plugin’s settings for any capability-based REST API filtering and adjust to allow the affected role’s save requests. According to the WordPress REST API documentation, post save requests require authenticated access via cookie nonce or application password authentication — any security layer that strips authentication headers causes the save to fail with a 401 or 403 response.
Server Limits Causing Save Failures
Server limits cause WordPress post not saving for posts that exceed specific size or time thresholds. These failures are particularly common with long-form content, posts with many embedded blocks, or posts with large metadata.
The three most relevant server limits are:
- post_max_size — the maximum size of a single POST request. Posts with many blocks, large amounts of embedded code, or extensive custom fields can exceed the default 8MB limit. The block editor sends the entire serialised post content in a single API request — if this exceeds post_max_size, PHP rejects the request entirely and the editor shows a save failure. Increase in php.ini or .htaccess:
php_value post_max_size 32M. - max_execution_time — the maximum time PHP runs before timing out. Complex posts with many blocks, custom field processors, or save hooks that do significant computation may exceed the 30-second default. Increase with:
php_value max_execution_time 120. - memory_limit — PHP memory exhaustion during a save produces a fatal error and a failed save. Increase via wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
After increasing any limit, retry the save — if it works, that limit was causing WordPress post not saving — if it succeeds, the limit was the cause. Our guide on increasing WordPress memory limit covers all three methods for adjusting PHP configuration on different hosting environments, relevant when server limits are causing WordPress post not saving on content-heavy posts.
Plugin and Browser Conflicts Blocking Saves
Plugins that hook into the save_post action or modify the REST API response can cause WordPress post not saving by throwing errors during the save process or returning unexpected data that the block editor cannot parse as a valid save response.
Test with all plugins disabled: Health Check → Troubleshooting Mode → enable → attempt the save. If the post saves correctly with all plugins off, a plugin’s save hook is the cause. Re-enable plugins one at a time, testing saves after each, until the failure returns. SEO plugins (which process post content on save for analysis), backup plugins (which trigger on post save), and custom field plugins (which save additional metadata alongside the post) are the most common sources of save-blocking errors. A plugin that throws a PHP warning or notice during its save hook can corrupt the JSON response the editor expects, causing the “not a valid JSON response” error without the plugin itself crashing WordPress.
Browser-specific WordPress post not saving failures — where Chrome fails to save but Firefox succeeds, or vice versa — point to a browser extension conflict rather than a WordPress issue. Privacy-focused browser extensions that block third-party cookies, tracking requests, or API calls sometimes intercept the block editor’s REST API save request. Test in a private browsing window (where most extensions are disabled) — if saves succeed there, a browser extension is blocking the save in the normal browsing context. Disabling extensions one at a time in normal browsing mode identifies the specific offender. Ad blockers with aggressively curated lists sometimes include WordPress REST API endpoints in their block rules — whitelisting the site domain in the ad blocker resolves this immediately. Reviews from the WordPress support community confirm that expired nonces, REST API blocks, and server PHP limits together account for the majority of WordPress post not saving cases across all recent WordPress versions.
The WordPress autosave system provides a safety net when WordPress post not saving loses content: WordPress saves a draft copy in the database every 60 seconds by default. If a save failure results in content loss, navigate to Posts → All Posts → find the post → click to edit → in the block editor, look for the “Revisions” panel in the right sidebar → click “Browse all revisions” → find the most recent autosave or revision. WordPress stores autosaves separately from revisions, and both are accessible through the revisions browser. The autosave timestamp shows the exact moment the last successful autosave occurred — any content written after that timestamp was not captured and must be rewritten. Reducing the autosave interval from 60 seconds to 30 seconds (add define('AUTOSAVE_INTERVAL', 30); to wp-config.php) minimises potential content loss from future WordPress post not saving events.
Database write failures cause WordPress post not saving in a way that produces no visible error in the editor — the save appears to complete (spinner stops, no error notice) but revisiting the post shows the previous version. This occurs when the database user account lacks INSERT or UPDATE permissions on the wp_posts table, or when the database server is under high load and times out the write operation. Check: Settings → Site Health → Database → if any permissions errors appear, the database user needs the correct grants. Contact the hosting provider with the specific error from Site Health to get the database permissions corrected. For high-load write timeouts, the fix is server-side — hosting providers can increase the MySQL query timeout or move the database to a dedicated instance with more resources.
Using the Classic Editor plugin as a temporary workaround for persistent WordPress post not saving in the block editor allows content to be published while the root cause is investigated. Install Classic Editor → the classic editor uses a different save mechanism (standard form POST rather than REST API) that bypasses most block editor-specific save failures. If the classic editor saves successfully, the problem is definitively in the block editor’s JavaScript-REST API save chain rather than in WordPress core’s post saving infrastructure. This narrows the investigation to JavaScript conflicts, browser extensions, and REST API authentication issues. Once the root cause is identified and fixed, the classic editor can be deactivated and block editor workflows restored.
Multisite WordPress installations have an additional WordPress post not saving failure mode related to sub-site permissions. A user who is an Administrator on the network level but only an Editor on a specific sub-site may encounter save failures on that sub-site because network-level capabilities do not automatically translate to all sub-site permissions. Verify the user’s role assignment on the specific sub-site (not the network admin) by navigating to that sub-site’s admin → Users → find the user → confirm they have at minimum Author role, which includes the edit_posts and edit_published_posts capabilities required for saving existing posts. Super Admins bypass this check, but users without super admin status must have explicit role assignment on each sub-site where they need to save content.
Checking the WordPress error log immediately after a failed save provides the most precise diagnostic for persistent WordPress post not saving cases. Enable debug logging: add define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); to wp-config.php → attempt a save → check /wp-content/debug.log. The log entry shows exactly which PHP file threw an error, at which line, and what the error was — pinpointing the problematic plugin, theme function, or WordPress core condition causing the save failure without requiring the lengthy plugin-by-plugin isolation process.
The Gutenberg block editor stores draft content in browser localStorage as an additional recovery layer when WordPress post not saving causes content loss. After a failed save, before reloading the page, open browser DevTools → Application tab → Local Storage → find entries starting with “wp-autosave-block-editor” or similar — these contain the serialised block content from the most recent browser-side autosave. Copying this JSON content provides a manual recovery path even when the WordPress autosave was not captured in the database. This local storage recovery is a last resort but has saved hours of rewriting for editors who experienced a catastrophic save failure during a long writing session. Related: WordPress Category Page 404.
