How to Fix Updating Failed. The Response Is Not a Valid JSON Response in WordPress

Mid-edit, the WordPress Block Editor can stop saving and throw this at you: Updating Failed. The Response Is Not A Valid JSON Response.

It sounds like you’ve written something wrong in the post. Most of the time, you haven’t. The editor asked WordPress to save your work, and the server sent back something the editor couldn’t read.

If this started right after site maintenance, treat it like a broken WordPress update too: save the content first, then diagnose the smallest reversible fix.

TL;DR: Save your draft outside WordPress, take a backup, and start with low-risk checks like permalinks, URL settings, and Site Health. If the editor still fails, review the /wp-json/ request: 403 often points to WordPress security rules or firewall blocks, 404 to broken routing, 500 to server errors, and 301/302 to redirects catching the request.

Save the post before fixing the site

Don’t start troubleshooting while the editor tab is the only place your writing exists. Get the writing out of WordPress:

If the post has to go out today, Classic Editor can be a temporary bridge. It may let you publish because it doesn’t use the exact same save path as the Block Editor. That’s useful in a pinch, but come back to the REST problem after the immediate deadline.

Make a backup before changing settings, testing plugins, switching themes, or touching server files.

What the JSON error means

The Block Editor saves posts by calling WordPress’s REST API. On a normal save, WordPress sends back JSON, which is structured data the editor can read.

This error appears when the editor gets something else instead:

That’s why I don’t start by looking for “bad JSON” inside the post. I want to know what the save request actually got back from the server.

In our baseline WordPress check, the REST index returned 200, the current user endpoint returned 200, and the posts route accepted write requests. That’s the boring version of events. The editor sends the request, WordPress answers in JSON, and the post saves. When this error appears, one part of that path has been interrupted: routing, login state, security filtering, PHP execution, or the final response body.

Try the low-risk fixes first

These checks are worth doing before you deactivate plugins or change themes. They don’t usually alter what visitors see.

Re-save permalinks

Open the Permalinks screen from Settings and press Save Changes once. Leave the permalink format exactly as it is.

This refreshes the rules WordPress uses to route clean URLs. On Apache hosting, those rules often live in .htaccess. If they are stale or damaged, a REST request can hit a 404 page instead of WordPress.

Then try updating the post again. On Nginx hosting, this may not be enough. Nginx doesn’t use .htaccess, so rewrite problems usually need someone with server access to inspect the config.

Check the site URLs

Open Settings > General and look at the two address fields near the top: the installation URL and the public site URL.

Check the details, not just the domain:

A mismatch can send the editor through a redirect or break the logged-in save request. The front end can still look fine while the editor gets HTML instead of JSON.

Be careful with URL changes. Saving the wrong address can make wp-admin unreachable until someone corrects the value in the database or in wp-config.php. If the fields are greyed out, those values are probably defined elsewhere.

Check Site Health

Open Tools > Site Health and look for REST API warnings.

Site Health won’t catch every cause, but it’s a good early clue. If WordPress says the REST API is unavailable, blocked, or returning an unexpected result, follow that lead before you start taking the site apart.

Find the failed REST request

If the quick checks don’t fix it, use the browser Network panel. Ignore most of what it shows. You need the failed request and the status code.

In Chrome or Edge:

1. Right-click the editor page and choose Inspect.
2. Open Network.
3. Filter by Fetch/XHR.
4. Click Update or Publish again.
5. Look for a request containing /wp-json/ or rest_route=.
6. Click it and check the Status and Response.

Use this as your map:

What you see	What to check next
301 or 302	URL settings, SSL rules, redirect plugins, CDN redirects
401 or a login page	Session, cookies, permissions, login rules
403	Firewall, ModSecurity, Cloudflare, host security, security plugin
404	Permalinks, rewrite rules, REST routing, Apache/Nginx config
500	PHP error, plugin/theme crash, custom code, server logs
HTML or warnings before JSON	Shortcodes, custom blocks, theme functions, PHP warnings

Don’t paste full request headers into a public forum. They can include cookies and security tokens. Share the REST path, status code, failure time, and a safe snippet of the response body.

Fix the cause you found

Now that you’ve found the failed request, focus on the system blocking, redirecting, or breaking it.

If it is a 404

The REST route probably isn’t reaching WordPress. Try this:

If /wp-json/ does not reach WordPress, give your host that exact test result and ask them to inspect rewrite handling. On Apache, that usually means .htaccess. On Nginx, it means server-level routing.

Make a copy of your site before touching .htaccess. It may contain redirects, cache instructions, security rules, or host-managed additions that will be painful to reconstruct.

If it is a redirect

A 301 or 302 means something is sending the REST request somewhere else.

Start with the most common redirect sources:

The sneaky version is a rule that sends /wp-json/ to the homepage. Visitors won’t notice. The editor will, because it asked for JSON and got a web page.

If it is a 403

A 403 is a refusal, not a missing page.

Check the layers that can refuse editor traffic:

Sometimes the content of the post is the trigger. A code path, shell command, bracketed snippet, or pasted HTML can look risky to a firewall rule even when you’re doing normal editing.

Temporarily disabling a firewall can confirm the cause, but don’t leave protection off. Find the exact blocked event and create a targeted allowlist for that REST request or rule. MalCare can help with website security visibility, but it isn’t a magic fix for a bad redirect or broken server response.

If it is a 500

A 500 means the server hit an error while trying to process the save.

Turn on logging, reproduce the failed update, and read the newest entry in wp-content/debug.log. The log may point to a plugin file, a theme file, or the exact shortcode/custom block that ran during the request. It may also show a PHP memory problem or another server limit.

Keep debug display off on a live site. Visible warnings can expose file paths, and they can also break the JSON response by printing text before WordPress sends the real data.

If there is HTML or a PHP warning

The response may be almost right and still fail. One warning before the JSON body is enough. Check the code that runs during save or preview:

If only one post fails, duplicate it and remove the newest suspicious block or shortcode. If the copy saves, you have a much smaller problem than a site-wide REST failure.

Test plugins and themes without breaking the site

Plugin and theme conflicts are real. I just wouldn’t make them the first move on a live site unless the evidence points there.

Run this somewhere visitors can’t trip over it, ideally a clone of the site. If production is the only option, take a backup first and choose a quiet window. A plugin test can disable checkout or forms. It can also change caching, custom blocks, and security rules while visitors are using the site, which is a lot of blast radius for a test you could have run elsewhere.

Begin with the plugins that sit closest to editor saves:

Deactivate one likely plugin, test the save, and reactivate it if nothing changes. If you already deactivated everything and the error disappeared, restore plugins in small batches until the error returns.

Themes need the same caution. A theme can break the response through editor scripts, shortcodes, custom blocks, or render code. Try one of the bundled WordPress themes on a clone before the public design gets involved.

Also check the less obvious layers:

If the normal plugin list looks clean and the error still behaves like a conflict, move outward from WordPress admin. Your host or developer can inspect those hidden layers.

If the error happens during image upload

The same message can appear when you add an Image block or upload media inside the editor.

Try Media > Add New first. If that works, the media library may be fine and the editor upload request may be the problem.

For one failing file, rename it:

If every upload fails, check upload size limits and file permissions first. After that, look at PHP errors and security logs.

I wouldn’t rebuild the whole site because one image filename upset the upload request. Prove that the failure is global before you treat it like a global problem.

Give your host the useful details

Host support can do much more with the failed request than with the editor message alone.

Send something like this:

I’m getting Updating failed. The response is not a valid JSON response in the WordPress Block Editor. The failing request is [REST URL path] and it returns [status code] at [time and timezone]. Can you check server logs and any firewall, ModSecurity, WAF, redirect, or routing events for that request?

Match the ask to the status code:

With the path, status code, and time, support can search the logs instead of trying to reproduce the whole editing session.

Prevent the next editor save failure

After the editor saves again, clean up the conditions that made the error likely.

FAQs

What does “Updating failed. The response is not a valid JSON response” mean?

It means the WordPress editor expected JSON from the server and got something else. That response might be a redirect, login page, firewall block, error page, PHP warning, or broken REST API route.

Did I put invalid JSON in my post?

Usually, no. Your post content can trigger the problem in rare cases, especially with code snippets or pasted HTML, but the error is about the server response WordPress received while saving.

Can permalinks cause this error?

Yes. Broken permalink or rewrite rules can stop /wp-json/ requests from reaching WordPress. Re-saving Settings > Permalinks is a good early fix, especially on Apache hosting.

Can Cloudflare or ModSecurity cause it?

Yes. Cloudflare, ModSecurity, host firewalls, and security plugins can block REST requests and return 403 responses or challenge pages. Check the security event log and allow only the specific blocked request when possible.

Is Classic Editor a real fix?

No. It can help you publish while the Block Editor is failing, but it may only bypass the broken save path.

Use it to rescue the work. Then go back and fix the underlying REST failure, because other WordPress features may rely on the same path.

Conclusion

The Updating Failed. The Response Is Not A Valid JSON Response error gets easier once you stop reading it as a writing problem. The editor asked WordPress for structured data and got the wrong reply.

Start by protecting the post and making the site restorable. Then check permalinks, URL settings, and Site Health. If those don’t solve it, use the Network panel to read the failed REST request. The status code usually points to the right owner of the problem: routing, security, redirects, or server errors.