You have spent twenty minutes on a page in the block editor, you click Update, and a red bar appears at the top: “Updating failed. The response is not a valid JSON response.” On a new post the wording is “Publishing failed. The response is not a valid JSON response.” The same message can also turn up when you add an image to a block.
The first thing to know is that your work is probably not lost. Do not close the tab. Copy the content of the page into a text file or another document before you try anything else, because some fixes involve reloading the editor. Then read on. This error is annoying but very fixable, and the cause is usually one of a handful of things.
What the message is telling you
The block editor runs in your browser. When you save, it does not submit a form the old-fashioned way. It sends your content in the background to your site’s REST API, at an address like /wp-json/wp/v2/pages/123, and expects a reply in a structured data format called JSON.
“Not a valid JSON response” means the reply came back as something else. It might be an error page from the server, a login page, a firewall’s block page, a 404 page, or valid data with a PHP warning stuck to the front of it. The editor cannot read any of those, so it reports a failure. The message is generic; the real cause is in the reply the browser received.
See the actual reply first
This takes two minutes and saves a lot of guessing.
- In Chrome, Edge or Firefox, press F12 (or right-click and choose Inspect) to open the developer tools, and click the Network tab.
- Click Update in the editor again so the error repeats.
- In the list of requests, look for one whose name includes your post or page ID, often shown in red. Click it.
- Look at the Status code and then the Response or Preview tab.
What you find points you straight to the right fix below:
- Status 403 with a page mentioning a firewall or security product: something is blocking the save.
- Status 404: the API addresses are not being routed to WordPress.
- Status 500: PHP crashed while saving.
- Status 200, but the response starts with “Warning:”, “Notice:” or “Deprecated:”: stray PHP output is spoiling the reply.
- A redirect to http, https, www or another domain: your site addresses do not match.
The usual causes, most likely first
1. A firewall blocking the content you are saving
This is very common, and it explains a pattern people find baffling: the page saves fine until you add a particular paragraph, an embed code, a table of code samples or a word that looks like a database command. Server firewalls such as ModSecurity, and CDN firewalls, inspect the data being sent and block requests that look like attacks. A legitimate page about SQL or a block of HTML can match their patterns.
The test is simple. Remove the most recent chunk of content and save. If it works, the firewall is reacting to that content. Your host can look up which rule fired and add an exception for your site’s admin area; CDN dashboards usually show blocked requests in an events log.
2. The REST API is blocked or broken
If no page saves at all, check Tools → Site Health. If it reports a REST API problem, fix that first; our post on “The REST API encountered an error” walks through it. Security plugins that disable the API are a frequent cause.
3. Permalink or rewrite rules
A 404 on save usually means the /wp-json/ addresses are not reaching WordPress. Opening the Permalinks screen under Settings and pressing the save button, with the same structure still selected, makes WordPress regenerate its rules, and very often the next save in the editor goes through.
4. Mismatched site addresses
On the General settings screen, the WordPress Address and the Site Address should match the way the site is really served. If one says http:// and the site is served over https://, or one includes www and the other does not, the editor’s background request can be redirected, and a redirected save often fails this way. It is a common leftover from moving to HTTPS or changing hosts. Our articles on mixed content after switching to HTTPS and on errors after moving a WordPress site cover the wider clean-up.
Be careful editing these two fields. A typo can lock you out of the dashboard. Take a database backup before you change them, and change only the scheme or the www, nothing else.
5. PHP warnings printed into the reply
If error display is switched on, any warning a plugin or theme raises while the save runs gets printed straight into the JSON reply, which spoils it. This is the same mechanism behind the “headers already sent” warning. Turning display off and sending errors to a log instead fixes the symptom; fixing the plugin that raises the warning fixes the cause.
6. A plugin conflict
A plugin that changes every API response, adds output to every request, or redirects admin traffic can produce this error on every save. SEO, caching, security, translation and membership plugins are the ones we would test first.
7. Caching the wrong thing
Some caching setups, especially at the server or CDN level, cache or alter requests they should leave alone. Logged-in requests and anything under /wp-json/ should normally be excluded from page caching.
A sensible order to work through
- Save your content somewhere safe outside WordPress.
- Back up the site before changing settings or plugins. A database copy is the minimum, since several fixes below touch settings stored there.
- Check the Network tab as described above and note the status code.
- Resave permalinks. Harmless, and often enough.
- Check Settings → General for an http/https or www mismatch.
- Try saving a short test post. If a tiny post saves but your real page does not, suspect the firewall and the content.
- Check Site Health for REST API and loopback problems.
- Pause caching and security plugins one at a time and try again, switching each back on afterwards.
- Test for a wider plugin conflict on a staging copy by deactivating plugins in groups. If it turns out two plugins cannot live together, our help for a plugin conflict is the next step.
- Ask the host to check their firewall log for the exact time of your failed save. Give them the time and your IP address.
When it only happens with images
A variation of the message appears when you drop an image into an Image block or the cover block and the upload fails. The same background request is involved, so the same causes apply, plus a few that are specific to uploads. The file may be larger than the server allows, in which case the reply is a server error page rather than data. The server may run out of memory while creating the smaller copies of a large photo. Or a security rule may dislike the file name or its contents.
A useful check is to upload the same image through Media → Add New instead of the editor. If the media screen gives a clearer message, such as a size limit, you have your answer. If it fails there too with a vague “HTTP error”, the problem is the upload itself rather than the editor, and resizing the image on your computer before uploading is a quick way round it while you fix the limit properly.
When only one user sees it
If an editor on your team gets the error and you do not, compare what is different about them. A browser extension that blocks scripts or rewrites pages, such as an aggressive ad blocker or privacy tool, can interfere with the editor’s background requests. Try a private window with extensions off. Also check their user role: some plugins change what lower roles are allowed to send, and a restriction meant for visitors can catch authors by mistake.
What about the Classic Editor workaround?
Installing the Classic Editor plugin makes the error disappear, because the classic editor saves by submitting a normal form rather than going through the REST API. That can be a fine short-term way to get a page published. It is not a fix. The underlying block on the API is still there, and other features that rely on it, including some forms and WooCommerce screens, will still be failing. Our post on block editor problems covers when sticking with the classic editor is a reasonable choice and when it just hides something.
Preventing it next time
- Keep error display switched off on the live site, and logging switched on.
- After changing hosting, adding SSL or putting a CDN in front of the site, open the editor and save a test draft the same day.
- If your pages regularly contain code samples or embeds, ask your host to tune their firewall for your admin area rather than disabling it.
- Write long pages in drafts and save often, so one failed save never costs much.
This error belongs to the same family as several others where the browser and server stop understanding each other. The WordPress errors and fixes guide lays out the whole family and how they connect.
Still not saving?
If you have resaved permalinks, checked the addresses, and pages still refuse to save, the cause is usually a firewall rule or a plugin interaction that needs logs to pin down. Send us a screenshot of the error and, if you can, the Network tab response. We will take a backup, find what is turning the reply into something the editor cannot read, and tell you what it was. This is everyday work for our WordPress repair service.
Next in this series: WordPress Debug Mode: Turn On WP_DEBUG Safely
