The message means WordPress sent a save request through its REST API, but the server returned something the Block Editor could not parse as JSON. The response may be an HTML error page, redirect, firewall challenge, login screen, PHP warning, or empty response. It usually does not mean that your post content is malformed.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Find the failed /wp-json/ request, note its HTTP status and response body, then repair the layer that produced it. The fastest fixes are refreshing rewrite rules for a 404, correcting URL or HTTPS settings for redirects, isolating plugins and themes for 500 or malformed responses, and allowing the REST route through a firewall for 403 responses.
As an Amazon Associate I earn from qualifying purchases.
What the invalid JSON message actually means
The Block Editor relies on WordPress’s REST API to load editor data and save posts and pages. A normal save request returns a JSON document with a success or error structure. The editor displays “Updating failed. The response is not a valid JSON response” when the HTTP response cannot be parsed as that document.
The editor banner is therefore a symptom, not a diagnosis. Several unrelated failures can produce it:
- A 404 page because the web server is not routing
/wp-json/requests to WordPress. - A 403 response, CAPTCHA, or “access denied” page from a WAF, ModSecurity, CDN, or security plugin.
- A 301 or 302 redirect caused by mismatched HTTP/HTTPS or www/non-www settings.
- A 500 response, PHP warning, fatal error, or plugin-generated output inserted before the JSON.
- A timeout, connection failure, or overloaded host that prevents a complete response.
- A login page or other HTML document returned where the editor expected JSON.
Do not start by changing several settings at once. The failed request’s URL, status code, headers, and first lines of its body identify which layer needs attention.
Run a three-minute diagnosis before changing settings
1. Check Site Health
- In the WordPress dashboard, open Tools → Site Health → Status.
- Look for messages such as The REST API encountered an error, The REST API encountered an unexpected result, HTTPS warnings, or loopback warnings.
- Record the endpoint, HTTP status, Home URL, Site URL, HTTPS state, permalink structure, server details, and any rewrite or
.htaccessinformation shown.
Site Health can reveal whether WordPress believes its own addresses and secure connection are consistent. Treat its warning as a lead; the browser request still provides the definitive response that stopped the save.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Inspect the exact save request in your browser
- Open your browser’s Developer Tools and select the Network panel.
- Return to the editor and click Update or Publish again.
- Filter the request list for
wp-json, or identify the request whose URL contains a REST route. - Open that request and record its full URL, status code, response headers, content type, and the first lines of the response body.
A response with a JSON content type and valid JSON means the request reached WordPress; inspect the JSON error details for the next clue. An HTML document, redirect chain, firewall challenge, PHP notice, or blank body identifies the layer that must be repaired. Copy the timestamp and URL before closing the tools so a host or security administrator can correlate it with logs.
3. Test the REST index directly
- Log out of WordPress or use a private browser window.
- Open
https://your-domain.example/wp-json/, replacing the example host with your own domain. - Confirm whether the page returns a JSON document rather than a branded error page, login form, or redirect.
The result narrows the search:
- 404: routing, rewrite rules, or web-server configuration is probably wrong.
- 403: a firewall, security plugin, WAF, or access policy is blocking the endpoint.
- 500: PHP, a plugin, a theme, or the server is failing while generating the response.
- Repeated redirects: WordPress URLs, HTTPS handling, or reverse-proxy settings disagree.
- Timeout or connection failure: investigate hosting capacity, network connectivity, loopback access, and firewall logs.
This test does not replace testing the exact route that failed during saving. A site may answer the index while blocking a particular REST route.
Match the response to the likely cause
| Network or Site Health signal | Most likely layer | First corrective action |
|---|---|---|
404 on /wp-json/ or the save route |
Permalink or rewrite routing; web-server configuration | Resave permalinks, then verify Apache or Nginx rewrite rules |
| 403, CAPTCHA, “access denied,” or security HTML | WAF, ModSecurity, CDN, or security plugin | Allow the REST route and inspect firewall events |
| 301/302 loop or HTTP-to-HTTPS bounce | WordPress URL, proxy, or SSL configuration | Align WordPress addresses and proxy HTTPS handling |
| 500, PHP warning, or fatal error | Plugin, theme, PHP runtime, or host | Isolate components and review PHP and server logs |
| Timeout or connection failure | Host capacity, network, loopback, or firewall | Give the host the endpoint, timestamp, and connection details |
| Saves work only when one component is disabled | Plugin or theme conflict | Identify that component and update, reconfigure, or replace it |
Use the status code from the failed save request, not a guess based only on the editor wording. The same banner can accompany completely different status codes.
Fix a 404: refresh permalinks and repair rewrites
Refresh WordPress’s permalink rules
- Open Settings → Permalinks.
- Do not change the selected structure unless you have a separate reason to do so.
- Click Save Changes.
- Return to the editor, reload the page, and test the save again.
Saving this screen flushes WordPress’s rewrite rules. It is a safe first response to a 404 caused by stale routing, but it cannot repair a missing server directive, firewall block, PHP failure, or outage.
Verify Apache or Nginx routing
On Apache, confirm that the WordPress installation can use its rewrite configuration and that the relevant .htaccess file is present and writable when WordPress needs to update it. A host may need to enable rewrite support or correct the virtual-host directory rules.
On Nginx, permalink settings inside WordPress do not create the server’s routing rules. The Nginx server block must pass ordinary WordPress paths and REST requests to the WordPress front controller, usually the site’s index.php. If /wp-json/ returns 404 while ordinary pages work, ask the administrator to compare the active server block with the site’s intended WordPress rewrite configuration.
After a server change, retest the REST index while logged out and then test the exact save request. A cached 404 from a proxy can persist briefly, so clear the relevant cache only after confirming the origin configuration is correct.
Fix redirects and HTTP/HTTPS mismatches
A REST request can fail even when the final page looks correct if it is bounced between hostnames or schemes. Common examples include WordPress generating an HTTPS URL while the proxy reports HTTP, or the WordPress Address using one hostname while the Site Address uses another.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →- Open Settings → General.
- Check WordPress Address (URL) and Site Address (URL).
- Use the intended hostname consistently, including the same www or non-www choice.
- Use
https://when the site is intended to run over HTTPS. - Save the settings if you can do so safely, then sign in again and retest.
Site Health’s Home URL, Site URL, and HTTPS information can help expose a mismatch. If the site sits behind a reverse proxy or load balancer, the proxy must pass the original HTTPS state correctly; otherwise WordPress may issue a redirect on every REST request. Have the hosting administrator verify proxy headers and SSL termination rather than repeatedly changing dashboard URLs.
In Developer Tools, inspect the redirect chain. One redirect to the canonical URL can be normal. Alternating HTTP and HTTPS, or www and non-www, indicates a configuration loop that must be corrected at the URL or proxy layer.
Rank #3
Fix plugin and theme conflicts without losing control
A plugin or theme can add notices to REST output, reject a route, alter authentication, or trigger a PHP fatal error. A malformed response may therefore appear only on one site or only for one content type.
Use troubleshooting mode when available
- Install or open the Health Check and Troubleshooting feature if it is already approved for your site.
- Enable troubleshooting mode for your user rather than disabling components for every visitor.
- Test the same post save with plugins effectively disabled and a default theme active for your session.
- If the save works, reactivate plugins one at a time and repeat the test after each change.
- When the error returns, note the last component enabled. Test it again with other components disabled to confirm the conflict.
Troubleshooting mode is preferable on a live site because visitors generally continue seeing the normal configuration. If it is unavailable, schedule a maintenance window, take a current backup, deactivate components in a controlled order, and restore them immediately after each test.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchResolve the identified conflict
Update the conflicting plugin, theme, and WordPress installation where compatible updates exist. Review the component’s REST, firewall, caching, SEO, custom-field, and authentication settings. If a specific route is rejected, document that route rather than broadly allowing every request. If the component is abandoned or incompatible with the site’s PHP version, replace it after confirming that its data and settings can be migrated.
Do not leave all plugins disabled as a permanent “fix.” The goal is to identify the component, apply a targeted update or configuration change, and verify normal saves with the complete intended stack.
Fix 403 responses, CAPTCHA pages, and security HTML
A 403 response means a security layer refused the request. The response body often makes this obvious: it may contain a CAPTCHA, an access-denied heading, a vendor-branded HTML page, or an incident identifier instead of JSON.
- Record the exact REST URL and timestamp from Developer Tools.
- Inspect the security plugin, WAF, ModSecurity, CDN, and host firewall events for that request.
- Determine whether the rule blocked all of
/wp-json/or only one route and method. - Create the narrowest exception that permits the legitimate authenticated REST request.
- Retest the original save and confirm that unrelated protections remain enabled.
Some security systems flag long post content, custom-field payloads, or particular parameter names. An exception for the exact affected route is safer than disabling the entire firewall. If a CDN is serving the challenge page, the origin WordPress installation may be healthy; the CDN administrator must correct the rule or cache behavior.
For a route such as /wp-json/example/v1/fields/, provide the complete path to the administrator. A broad allowance for every URL can hide attacks and make later diagnosis harder.
Fix 500 errors, PHP warnings, and fatal responses
A 500 response or a body beginning with a PHP warning indicates that WordPress or the server could not complete the request. Even a warning that appears harmless can invalidate the JSON if it is printed before the opening brace.
- Copy the response body’s first lines and the exact request time.
- Check the WordPress debug log if logging is enabled safely and privately.
- Ask the host to review PHP-FPM, web-server, and application error logs for the same timestamp.
- Use plugin and theme isolation to identify a reproducible component failure.
- Check PHP memory, execution time, process limits, and the host’s resource dashboard if the failure occurs only with large content.
Do not display debugging output to visitors on a production site. Logging should capture the error without exposing paths, credentials, or stack traces in the HTTP response. Once the offending code is corrected, clear any stale page or object cache and repeat the save from a fresh editor session.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Handle timeouts and connection failures
If the request never receives a complete response, the browser may show a timeout rather than a useful status code. Possible causes include exhausted PHP workers, CPU or memory saturation, a blocked loopback connection, a network interruption, or a firewall that drops rather than rejects traffic.
- Check whether the REST index and ordinary dashboard pages are slow at the same time.
- Compare a logged-out request with the authenticated save request.
- Review host resource graphs and PHP-FPM worker limits around the failure time.
- Ask the host to test connectivity between the proxy, web server, PHP process, and database.
- Check firewall logs for dropped packets or rate limits affecting the site’s own domain.
Increasing timeouts blindly can conceal capacity problems. Supply the host with the endpoint, timestamp, status if any, response duration, and browser error so it can correlate web-server and PHP logs.
Use a controlled recovery workflow
When the cause is still uncertain, work from the least disruptive check to the most privileged change:
- Save the failed request details: URL, status, response type, body excerpt, and time.
- Test
/wp-json/while logged out. - Run Site Health and compare its URL and HTTPS findings with the request.
- Resave permalinks for a 404, without changing the permalink structure.
- Correct WordPress Address, Site Address, and proxy HTTPS handling for redirect loops.
- Use troubleshooting mode to isolate plugins and themes for PHP or malformed responses.
- Review WAF, CDN, ModSecurity, and security-plugin logs for 403 or challenge responses.
- Escalate 500 errors, timeouts, and resource problems with the collected evidence.
- Retest from a new editor session and confirm both the editor save and direct REST response.
Change one layer at a time and record the result. This prevents a temporary improvement from hiding the original cause and makes rollback possible.
What the error does not mean
- It does not, by itself, prove that the post text, block markup, or media is invalid.
- It does not mean that resaving permalinks will repair every case.
- It does not justify disabling all security controls or every plugin indefinitely.
- It does not identify whether WordPress, PHP, the web server, a proxy, or a firewall produced the bad response.
The status code and response body are the evidence needed to distinguish those cases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When to involve your host or security administrator
Escalate when you see persistent 403 responses, 500 errors, PHP fatals, connection timeouts, rewrite changes you cannot make, or a proxy that continually changes the request scheme. Include:
- The complete REST endpoint and HTTP method.
- The UTC timestamp and your site hostname.
- The status code, response headers, content type, and a safe excerpt of the body.
- Whether
/wp-json/works while logged out. - Site Health messages and whether plugin/theme troubleshooting changed the result.
- Any request or incident ID shown by the WAF or CDN.
Ask for review of the web-server access and error logs, PHP-FPM logs, WAF or ModSecurity events, proxy SSL handling, rewrite rules, and host resource limits. This information lets an administrator fix the failing layer instead of asking you to repeat unrelated dashboard changes.
Quick Recap
Final verification checklist
https://your-domain.example/wp-json/returns JSON while logged out.- The exact authenticated save request returns valid JSON, not HTML or a redirect.
- Site Health no longer reports a REST API or HTTPS error.
- The intended WordPress and Site URLs use one canonical hostname and scheme.
- Permalink rules are saved and the web server routes REST requests correctly.
- The necessary plugins and theme are active without reproducing the failure.
- Security exceptions are limited to the legitimate route and do not disable broader protection.
- A test post update and a new post publication both complete successfully.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
