Fixing "Updating failed. The response is not a valid JSON response"

You click Save or Publish in the block editor and, instead of your changes saving, a message appears at the top of the screen: "Updating failed. The response is not a valid JSON response." You might see the same message when uploading an image into a post, or a slightly different version that says "Publishing failed".

The block editor doesn't save your content by submitting a normal form. It sends it in the background to the WordPress REST API, which lives at /wp-json/ on your site, and expects a reply in a structured data format called JSON.¹ The error means something got in the way and WordPress received a reply it couldn't read. That reply is usually an HTML page instead: a 404 page, a firewall block page, a login screen or a PHP error message.

So the fix is finding out what's replying instead of the REST API. That's normally quicker than it sounds.

Test the REST API directly

Open a new browser tab and go to https://example.com/wp-json/, replacing example.com with your domain.

If the REST API is working, you'll see a page of structured text starting with something like {"name":"Your Site Name","description":.... Some browsers format it into a collapsible tree. Either way, that's JSON and it means the API is reachable.

If you see a 404 page, a blank page, a "forbidden" message or a redirect to somewhere else entirely, you've found the problem area. Work through the sections below on permalinks, site URLs and firewalls.

You can also check Tools → Site Health. If WordPress can't reach its own REST API, Site Health shows an issue titled "The REST API encountered an error" or "The REST API encountered an unexpected result", along with the error it received.²

Look at the failing request

If /wp-json/ loads fine but saving still fails, the browser's developer tools will show you exactly what came back.

1. In the editor, open developer tools (F12, or right-click and choose Inspect) and select the Network tab.
2. Click Save or Update to trigger the error again.
3. Look for a request shown in red, usually with a name starting with the post ID or posts, pages or media.
4. Click it and open the Response (or Preview) tab.

The response tells you what's actually replying. A PHP warning or notice at the top means a plugin or theme is printing errors into the output. A page mentioning ModSecurity, Cloudflare, Wordfence or "access denied" points at a firewall, and our guide to the 403 forbidden error covers the same culprits. A login form means your session or cookies aren't being recognised. A 404 page points at permalinks.

Reset your permalinks

The /wp-json/ address relies on the same rewrite rules as your pretty permalinks. If those rules are missing or corrupted, the REST API returns a 404 and the editor can't save.

On Apache and LiteSpeed servers, saving your permalink settings rewrites the WordPress section of your .htaccess file. WordPress only touches its own section, but if the file contains custom redirects or security rules, download a copy of it first so you can put it back if anything goes wrong.

Then go to Settings → Permalinks and click Save Changes without changing anything. This regenerates the rewrite rules.

If that doesn't help and you're on Apache, check that .htaccess exists in your site's root folder and contains the default WordPress rules.³ On Nginx there's no .htaccess, so the server configuration needs a try_files rule that passes requests to index.php.⁴ Your host can confirm this.

Our permalink and 404 troubleshooting guide covers rewrite rule problems in more depth.

Check your WordPress and site URLs

Go to Settings → General and look at the WordPress Address (URL) and Site Address (URL). Both should match exactly, and both should match the address in your browser's address bar, including https:// and whether or not you use www.

If your site loads over https:// but these settings still say http://, or one has www and the other doesn't, the editor's background requests can be redirected, blocked by the browser as insecure or sent without your login cookie. Any of those will produce the JSON error.

Changing these values logs you out, and a typo can lock you out of the dashboard entirely, so note down the current values before you change them. If it does go wrong, our guide to regaining access to WordPress admin shows how to fix the URLs from wp-config.php. If you've recently moved the site to HTTPS, our guide to fixing "Not Secure" warnings and mixed content walks through updating URLs properly, and mismatched URLs can also cause redirect loops.

Rule out firewalls and security plugins

Firewalls are one of the most common causes, and they tend to produce the error only on certain posts. A web application firewall inspects the content you're saving, and if it spots something that looks like an attack (a block of JavaScript, an embed code, some SQL in a code sample, even certain combinations of words), it blocks the request and sends back its own HTML page.

If the error only happens on one post, try removing recently added blocks one at a time, especially Custom HTML blocks, embeds and code samples, and save after each. If the post saves once a particular block is gone, a firewall rule is almost certainly the cause.

Then check each layer that could be filtering requests:

• Security plugins such as Wordfence, Solid Security or All-In-One Security. Temporarily deactivate them, or use their learning mode or allowlisting features to allow the blocked request. Make a note of any settings you change so you can switch them back afterwards.
• Cloudflare or another CDN. Check the security events log in your Cloudflare dashboard for blocked requests to /wp-json/. If a rule is blocking genuine edits, it can usually be adjusted or given a narrow exception. Firewall exceptions weaken your protection, so keep any exception as narrow as possible, and ask whoever manages your Cloudflare account if you're not sure.
• Server-level firewalls like ModSecurity or Imunify360. You can't see these from WordPress. Give your host the time you saw the error and the URL of the failing request, and ask them to check their firewall logs for a false positive.

Check for plugin and theme conflicts

A plugin can break the REST API in a few ways: disabling it outright (some security and "performance" plugins offer this as a setting), adding output before the JSON response or throwing a PHP error during the save.

Deactivate plugins one at a time, trying to save after each. Deactivating plugins switches their features off for visitors too, so do this at a quiet time or on a staging copy if you can. When saving starts working, the last plugin you deactivated is the likely cause. Reactivate the others and check they're all active again. A plugin with a setting like "Disable REST API" or "Restrict REST API to logged-in users" is worth checking first, since the second option in particular can go wrong when combined with caching.

To rule out your theme, switch temporarily to a default theme such as Twenty Twenty-Five and try again. This changes how the site looks to visitors, so do it on a staging copy or at a quiet time, and switch back afterwards.

If the error started straight after an update, our guide to recovering a site broken by an update covers rolling back safely.

Stop PHP errors printing into responses

If the Network tab showed PHP warnings, notices or "Deprecated" messages before the JSON, WordPress is displaying errors on screen. That's fine on a development site but it breaks the editor, because the error text corrupts the JSON.

Download a copy of wp-config.php before editing it. A single stray character in that file can take the whole site offline with a critical error, and having the original means you can put it straight back.

Open wp-config.php and check for these lines. On a live site they should look like this:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

If you need to keep debugging switched on while you investigate, log errors to a file instead of displaying them:⁵

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Errors will then be written to wp-content/debug.log, and the editor gets clean JSON. The underlying warning still points at a plugin or theme that needs updating, so it's worth tracking down. Switch debugging off again when you've finished, since the log file can reveal details about your server.

Check caching isn't serving REST responses

Page caching should never apply to the REST API or to logged-in users. If a caching plugin, your host's cache or a CDN rule caches /wp-json/ responses, the editor can receive a stale or wrong reply.

Clear every cache layer (our guide to a WordPress site not updating walks through each one), then check your caching settings for an exclusion covering /wp-json/ and for logged-in users. If you use a Cloudflare "Cache Everything" rule, make sure it excludes /wp-admin/ and /wp-json/, and bypasses the cache when a WordPress login cookie is present.

Image uploads showing the same error

If the error only appears when you upload images inside the editor, the upload itself is failing and the editor is reporting it badly. The cause is usually a file size limit, folder permissions or an image processing error on the server. Try uploading the same file through Media → Add New, which tends to show a more useful message, and see our guides to fixing WordPress media upload errors and fixing "The link you followed has expired".

Don't just switch to the Classic Editor

Installing the Classic Editor plugin will often make the error go away, because the classic editor saves through a normal form rather than the REST API. But the REST API is still broken, and other things rely on it: Site Health, some plugins, WooCommerce admin screens, the mobile apps and many integrations. Treat it as a way to get an urgent post out while you fix the real problem.

Still can't save?

If you've tested the REST API, reset permalinks and ruled out firewalls and plugins but the error keeps coming back, the problem is likely at server level. Your host can check error logs and firewall rules that aren't visible from WordPress. My WordPress development service and emergency WordPress support cover REST API problems, firewall conflicts and editor errors, including cases where the fix needs server access.