You press Update on a post and WordPress answers:
The response is not a valid JSON response.
The post may or may not have saved. The message tells you nothing about what went wrong, and searching for it produces a pile of advice that starts with "switch your permalinks to Post name" — which sometimes works, and nobody explains why.
Here is what is really happening, and how to find your own cause in a few minutes instead of trying fixes at random.
What the message actually means
When you save a post, the block editor sends the content to the REST API and expects JSON back. Something like:
{ "id": 42, "status": "publish", "title": { "raw": "Hello" } }
The editor takes that response and runs it through a JSON parser. If the text is not valid JSON, the parser throws, and the editor shows you the only thing it knows: the response was not valid JSON.
The key point: the JSON is not broken. There is no JSON at all. The server sent something else — an HTML error page, a PHP warning, a redirect page, a firewall block — and the editor is reporting that it could not parse it.
That is why this error has a dozen unrelated causes. It is not one bug. It is one symptom of everything that can go wrong between your browser and wp-json.
Step one: look at what the server actually sent
Stop guessing and read the response. It takes thirty seconds.
Open developer tools with F12, go to the Network tab, press Update again, and find the failed request — it will have wp-json in the name. Click it and open the Response tab.
Now you can see the real answer, and it is usually one of these:
HTML starting with <!DOCTYPE html> — the server returned a web page instead of data. Almost always an error page or a redirect. The next lines usually name the culprit.
A PHP warning followed by correct JSON, like this:
Warning: Undefined variable $x in /wp-content/plugins/some-plugin/file.php on line 88
{"id":42,"status":"publish"}
This one is worth understanding. The JSON is perfectly fine, but a plugin printed a warning _before_ it. The output is now warning-then-JSON, which as a whole is not valid JSON. The parser hits the letter W and gives up. A single stray echo in any plugin breaks saving for the whole site.
A 403 or a block page — a security plugin or your host's firewall decided the request looked suspicious.
Nothing at all, or a 404 on the wp-json URL — the REST API is not reachable, which is the case where permalinks actually matter.
Step two: paste it into a JSON checker
If the response looks like JSON but the editor rejects it, copy it into any JSON validator and see where it breaks. The point is to get a line and column number instead of a feeling.
For the warning case above, a checker says exactly this:
Unexpected token 'W', "Warning: U"... is not valid JSON
That single line tells you the response starts with text, not with data — and the text names the plugin file to disable.
For a genuinely malformed structure you get the position:
Expected double-quoted property name in JSON at line 4 column 1
Now you have a place to look, rather than a general suspicion.
Step three: the four usual causes, in order of likelihood
A plugin printing output. Deactivate plugins one at a time, starting with anything recently installed or updated. The Warning: line in the response names the file directly, so read it before you start disabling things blindly.
Permalinks and the REST API. Go to Settings → Permalinks and press Save without changing anything. This rewrites the rules. It helps when /wp-json/ returns 404, and it is useless in every other case — which is why the advice works for some people and not others.
Security plugin or host firewall. Wordfence, iThemes and many hosting-level firewalls block REST requests that match a rule. The response is a block page, not JSON. Check the plugin's own log: the request will be there with the rule that caught it.
SSL and mixed URLs. If the site URL is https and WordPress is configured with http (or the other way round), the API call becomes a redirect. The editor follows it and receives an HTML page. Check Settings → General.
Step four: when the post saves anyway
Sometimes the error appears and the post is saved correctly. That is the warning case again: the data went through, the response was just polluted. The post is fine, the site is not — every save will keep failing visibly until the stray output is gone.
What not to do
Do not start by reinstalling WordPress. The error is in the exchange between browser and server, not in the core files.
Do not disable the REST API. Advice to block wp-json still circulates. The block editor runs on it: turning it off replaces one error with a broken editor.
Do not settle for the Classic Editor as a fix. It avoids the REST API and therefore avoids the message — but the plugin that prints warnings is still printing them, and it will break something else later.
The short version
The message says JSON. The cause is almost never JSON. Open the Network tab, read the actual response, and the first line of it will usually name the file to fix.