Fixing the Invalid JSON Response Error

The message describes the symptom, and the cause is readable in a browser tab. When you press Update, the block editor sends the post to the REST API and expects JSON back. It got something that is not JSON. WordPress cannot tell you what, because it could not parse it — but you can look at the reply yourself, and that single check turns a vague error into a specific one.

Look at the response first

Open this address, substituting your domain:

https://example.com/wp-json/

What comes back identifies the fault immediately:

Do this before changing anything. Every fix below applies to one of these rows, and applying the wrong one is how an afternoon disappears.

Permalinks and rewrite rules

The REST API is reached through a rewritten URL. If rewrite rules are stale or the rules file is missing directives, the endpoint 404s while ordinary pages still work, because they were cached into the rules earlier.

Resaving permalink settings regenerates the rules, which is the one-click version of the repair described in permalinks not working. On Apache, confirm the rewrite block is present and intact in the rules file — the expected content is set out in the default WordPress .htaccess file.

If the API 404s and so do pretty permalinks generally, fix the rewriting first; the JSON error resolves with it.

A security layer refusing the request

Firewalls, host-level rules and CDN configurations block REST requests more often than any other single cause, usually because the request method or a pattern in the payload trips a rule.

The tell is that /wp-json/ returns a block page rather than a 404, and that the block is more likely on posts containing code, script tags or unusual characters — a post that saves fine when short and fails when it contains a code sample is almost always this.

Resolving it means allowing the endpoint in whatever is doing the blocking. Disabling the protection entirely is not the fix, and neither is stripping content out of the post until it saves.

The site URL mismatch

If the stored site address does not match the address actually being used — http against https, or with and without www — the editor builds an API URL that redirects. A redirect is not JSON, and the parse fails.

Both addresses have to agree, and the reliable way to pin them is WP_HOME and WP_SITEURL. This cause appears most often right after a move to HTTPS or a domain change, alongside mixed content warnings.

Output printed before the JSON

JSON must be the entire response. A single character in front of it makes the whole thing invalid, and the usual source is a PHP file with a blank line after its closing tag, or a notice printed because something deprecated is still in use.

This one is invisible in the editor and obvious at the endpoint: the JSON is there, with a stray warning or a blank line above it. Turning on logging through debug mode — writing to a file rather than the screen — names the file and line. Displaying errors on screen while debugging this makes it worse, because the display itself becomes the output that breaks the response.

Narrowing to one plugin

If the endpoint looks correct and saving still fails, the remaining causes are code-level. Deactivate plugins in a group, confirm saving works, then reactivate in halves until the culprit appears — the standard procedure in fixing plugin conflicts.

Switch to a default theme in the same way before concluding. A theme's functions.php can print output exactly as a plugin can.

Verify properly

A successful save is not sufficient evidence. Save a post containing a code block, save a post with an embedded media item, and save a long post. The failures that survive a casual test are the ones triggered by payload size or content, and a short test post exercises none of that.

If saving now works but the editor still behaves oddly in other ways, the remaining problem is the editor itself rather than the API, and that starts at the block editor not working.