When the editor reports an invalid JSON response after Save or Publish, preserve your text and check whether the server stored the change. The editor may have received HTML, a redirect or warning text instead of the structured reply it expected.
Follow the actual failed request to distinguish authentication, routing, security rules and PHP output.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Response evidence | Investigation | First check |
|---|---|---|
| HTML login page | Session or redirect | Fresh authorized editing session. |
| 403 response | Permissions or security rule | Request path, time and rule identifier. |
| 404 response | REST routing | Post URLs and server rewrite configuration. |
| 500 response | Server failure | Matching protected error logs. |
| 200 with HTML or warnings | Unexpected response content | Response body and earliest PHP message. |
Protect the edit before testing
- Save a private copy of unsaved text.
- Reopen the post separately to see whether the change persisted.
- Try one small edit in a test draft.
- Compare the failed save response with the successful draft request.
Copy your unsaved text somewhere safe before refreshing the editor. Then open the public post separately and check whether the change was saved despite the error. The server may have completed part of the operation before the reply failed, so repeatedly pressing Publish can make the situation harder to follow.
Try a short change in a separate test draft. If that saves but the original post does not, compare the content involved. A large embedded block or a phrase that matches a security rule may trigger a different result from a plain paragraph. This is evidence to investigate, rather than a reason to strip useful content from every post.
Look at the request that failed
Useful report: include the endpoint path, request time, status and whether the reply starts with HTML, JSON or a PHP warning. Redact authorization values and private post content. A public REST index loading is only a discovery check; it does not test an authenticated save.
In your browser’s developer tools, the Network panel can show the request made when you save. Look for the failed request associated with the editor, often a REST API address containing wp-json or rest_route. Its status and response body help narrow the problem.
An HTML login page suggests a session or redirect issue. A 403 response may come from a firewall or a permissions check. A 404 page can indicate a routing problem. A 500 response calls for a matching server-log entry. Even a 200 response can fail if it contains an HTML page or PHP warning instead of clean JSON.
A JSON error response is also worth reading: it may explain an expired session or missing permission. Do not share a full network export publicly without reviewing it, because requests can contain cookies, tokens, and private post content.
Separate access problems from routing problems
If the editor has been open for a long time, a fresh login and a newly opened editing screen may restore the authentication state. WordPress’s browser-based REST authentication relies on the logged-in session and a nonce. A public API page loading successfully does not prove that an authenticated save request will work.
For routing problems, check whether your normal post URLs also fail. Saving the existing settings under Settings → Permalinks can refresh WordPress rewrite rules on supported setups. It does not repair every server configuration. An Nginx routing problem, for instance, needs the appropriate server configuration rather than an Apache .htaccess change.
Also review the WordPress Address and Site Address after a domain move or HTTPS change. They can legitimately differ when WordPress is installed in a subdirectory, so forcing them to match without understanding the setup can cause another problem. What matters is that the editor’s requests reach the intended site and are not sent through an unexpected redirect.
Find what is changing the response
A firewall may allow ordinary visits but block an authenticated save request. Give your host or security provider the failed request’s path, time, status, and any request identifier. A narrow rule adjustment based on that evidence is more useful than turning off protection across the site.
Optimization tools can also interfere if they cache administrative responses or combine scripts the editor needs. Test the suspected setting on staging where possible. If the error began immediately after a plugin change, compare the same small draft with that component paused, then restore the setting when the test is complete.
PHP warnings are another possibility. A warning printed before the JSON can make an otherwise successful response unreadable. The server logs should identify the code responsible. Keeping production errors out of the response is sensible, but hiding the message alone does not repair the underlying code.
Confirm that saving works again
Save a small edit, reopen the post, and check that the text is still there. Then repeat with the original content. This distinguishes a general repair from a workaround that only succeeds on an empty test post.
For related symptoms, see our guides to WordPress REST API errors, 403 access failures, and redirect loops. WordPress’s documentation explains REST authentication and API discovery and routing in more detail.
Confirm the original content saves correctly
Save, close and reopen the test draft, then repeat with the original content. Check the stored text and intended public status. If the response still fails while content saves, continue investigating the reply rather than repeatedly pressing Publish.