Updating Failed: The Response Is Not a Valid JSON Response (WordPress Fix)

You click Publish or Update in the block editor and a red bar appears at the top of the screen: 'Updating failed. The response is not a valid JSON response.' Sometimes it says 'Publishing failed' instead. The content is still in the editor, nothing is lost yet, but nothing saves either. The block editor talks to your site through the WordPress REST API at /wp-json/. When that request comes back as anything other than clean JSON, an HTML error page, a 403 from a firewall, a redirect, or an empty body, the editor cannot parse it and shows this message. The error text describes the symptom, not the cause, which is why generic advice rarely fixes it.

This error has a reputation for being hard because the message tells you nothing useful. 'The response is not a valid JSON response' is the editor's way of saying it asked the server a question and got gibberish back. The fix is never about the JSON. It is about finding which layer between the browser and PHP is returning something that is not JSON.

I keep a fixed order for this one because guessing wastes an hour and the checklist takes fifteen minutes. Permalinks first, then site URLs, then SSL, then plugins, then the server firewall. In roughly seven out of ten cases I never get past the first two steps.

Step 1: Find out whether the REST API works at all

Before changing anything, open a new browser tab and go to https://yoursite.com/wp-json/. A healthy install returns a dense block of JSON starting with a name, description, and a long routes object. That means the API is reachable and routing correctly.

If you get a 404 page, the rewrite rules are broken and Step 2 will most likely fix it. If you get a 403 or a security challenge page, a firewall is blocking the API and you can skip straight to Step 5. If the page is blank, PHP is fatally erroring before it can output anything and you should read your error log first.

Tools > Site Health > Status runs the same check inside WordPress and shows the HTTP status code it received. Between the browser test and Site Health you know within a minute which half of the checklist applies to you.

Step 2: Re-save permalinks (the fix that works most often)

Go to Settings > Permalinks. Do not change the structure. Just click Save Changes. WordPress regenerates its rewrite rules and, on Apache, rewrites the WordPress block inside .htaccess. That single click restores /wp-json/ routing on a surprising number of sites.

If your .htaccess is not writable, WordPress shows the rules on screen and asks you to paste them in manually. Do that over FTP or File Manager. On Nginx there is no .htaccess, so the equivalent is confirming the try_files directive in your server block, which your host controls.

# The standard WordPress block in .htaccess
# Missing or mangled rules here break /wp-json/ routing
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 3: Make the site URLs match reality

Open Settings > General and read both WordPress Address (URL) and Site Address (URL) carefully. They must match the exact address in your browser bar: same protocol, same www or non-www, no trailing slash. A mismatch means the editor requests the API on one host and the server redirects it to another. A redirect returns HTML headers, the editor sees no JSON, and you get the error.

If those fields are greyed out, they are hardcoded in wp-config.php with WP_HOME and WP_SITEURL. Edit them there instead. Change one line at a time and reload the editor between changes so you know which edit did what.

// wp-config.php: keep these identical to the URL you type in the browser
define('WP_HOME',    'https://example.com');
define('WP_SITEURL', 'https://example.com');

Step 4: Rule out SSL and mixed content

A half-installed certificate produces this error reliably. The admin loads over https, the REST endpoint resolves to http, and the browser refuses the request as mixed content. Nothing appears in your PHP log because the request never reaches PHP.

Open your browser's developer console on the editor screen and look at the Network tab while you hit Update. Find the request to wp-json/wp/v2/posts. Read its status code and its response body. A 301 or 302 means a redirect is in the way. A 403 means something blocked it. A 200 that contains HTML means a plugin or theme printed output before the JSON. Each of those points at a different fix, and the Network tab is the only place that tells you which one you have.

Step 5: Find the plugin or firewall that is blocking POST requests

If /wp-json/ loads fine in a browser but saving still fails, the block is specific to POST requests. That is the signature of a security plugin or a server-level web application firewall, because reading the API is harmless and writing to it is what they are configured to inspect.

Deactivate security plugins one at a time: Wordfence, Solid Security, All In One WP Security, Sucuri, NinjaFirewall. Retry the update after each deactivation rather than turning them all off at once, otherwise you learn nothing about which one is responsible. If a plugin is the cause, do not leave it off. Find its firewall log, locate the blocked request, and add a rule exception for the REST route.

Also check for plugins that print output on init. Any stray whitespace, notice, or echo before the REST response corrupts the JSON body. Switching to a default theme for two minutes rules the theme's functions.php in or out of that list.

Step 6: The mod_security rule your host will not mention

This is the case that sends people in circles for days. Everything looks correct, /wp-json/ loads, no plugin is at fault, and saving still fails on certain posts. What is happening is a server-level mod_security rule inspecting the POST body and blocking requests that contain patterns it treats as attacks: script tags, iframes, SQL keywords, long base64 strings, or shortcodes with unusual characters.

You cannot see those blocks from inside WordPress. Open a ticket with your host, give them the exact time you triggered the error and the URL of the post, and ask them to check the mod_security audit log for a blocked POST to /wp-json/wp/v2/posts. They will come back with a rule ID. Ask them to whitelist that rule for your admin paths, not to disable mod_security entirely.

• Symptom: only some posts fail, usually ones with embeds, code blocks, or raw HTML
• Symptom: the same content saves fine after you delete one specific block
• Symptom: /wp-json/ loads perfectly in a browser but POST requests fail
• Evidence to request: mod_security audit log entry with rule ID and timestamp
• Correct fix: a targeted rule exception, never a blanket mod_security shutdown

A publishing deadline that came down to one firewall rule

A recipe site on a shared host could publish short posts all day but every long recipe with an embedded YouTube video failed with this error. The owner had already reinstalled WordPress core, disabled every plugin, and switched themes twice. None of it helped because none of it touched the actual cause.

The Network tab told the real story in about thirty seconds: the POST to wp-json/wp/v2/posts returned a 403 with an HTML page from the host's firewall. The host confirmed a mod_security rule was matching the iframe in the embed. They whitelisted the rule for logged-in admin requests and every stuck recipe published on the first try.

The lesson I keep relearning: read the failing request before changing anything. The error message describes a parsing failure, but the Network tab tells you the status code, and the status code tells you which of the six causes you are dealing with.

Final checklist

Work these in order and stop at the first one that fixes it. Skipping ahead is how a fifteen-minute job becomes an afternoon.

• https://yoursite.com/wp-json/ returns JSON, not a 404 or a block page
• Settings > Permalinks has been re-saved once since the error started
• Settings > General shows the exact URL you type in the browser, protocol and www included
• The Network tab shows the status code of the failing wp-json request (200, 301, 403, or 500)
• Security plugins have been tested one at a time, not all disabled at once
• A default theme has been tried briefly to rule out output from functions.php
• Your host has checked the mod_security log if everything above passes
• Classic Editor, if installed, was a temporary workaround and has been removed after the real fix

1. 1Open Tools > Site Health > Info and check the REST API section, a failing REST API is reported there before you touch anything else.
2. 2Load https://yoursite.com/wp-json/ directly in a browser tab, you should see a wall of JSON, not a 404 page or a security block.
3. 3Go to Settings > Permalinks and click Save Changes without editing anything, this rewrites .htaccess and fixes the most common cause.
4. 4Confirm Settings > General has the correct WordPress Address and Site Address, matching protocol and www exactly.
5. 5Check for mixed content or a partially installed SSL certificate, an https page calling an http REST endpoint gets blocked by the browser.
6. 6Deactivate security and firewall plugins one at a time (Wordfence, iThemes, All In One WP Security) and retry the update after each.
7. 7Ask your host to check mod_security logs for blocked POST requests to /wp-json/wp/v2/posts, this is the cause nobody finds on their own.
8. 8As a temporary workaround only, switch to the Classic Editor while you finish diagnosing, it does not use the REST API for saving.