Preserve the edit before you try another fix
You click Update and WordPress displays “Updating failed. The response is not a valid JSON response.” Your immediate problem is practical: did the new text save, did the page publish, and can you safely close the editor?
Keep that editor tab open. Copy your changed text into a private document before refreshing or signing out. For a complex block layout, use the editor’s copy-all-blocks option if available and keep the copied content privately. Record the page URL and the time of the failed save.
Then open the same post in a second tab to inspect its stored content. Check the public page separately if it was already published. A preview, an autosave and a published page can show different versions. The error banner alone cannot tell you which one survived.
This guide concerns saving posts and pages in WordPress’s block editor. If the symptom is a missing or unresponsive Elementor button, use the separate Elementor publish-button guide. If the error happens during a file upload, start with our image-upload diagnosis.
Why a WordPress save can return an invalid JSON response
JSON is the structured reply the editor expects from its save request. The WordPress REST API reference explains that its requests and responses use JSON, including error responses. If a request receives a login page, a firewall challenge, an HTML error or unexpected output instead, the editor may be unable to read the result.
That message describes a failed exchange, not a single cause. A session problem, a blocked request, a routing fault or a plugin error can lead to similar wording. Valid JSON can also contain a specific error that needs its own diagnosis. Read the actual response before choosing a repair.
A save may involve more than one piece of data. A WordPress.org support report describes custom fields changing while post content did not. That is an individual case, not evidence of a universal WordPress bug. It illustrates why you should inspect the content and the fields independently.
Check each part of the save independently
Use this worksheet before another save attempt. Keep a copy of your intended changes so you can compare them with what WordPress actually stored.
| Part of the change | Where to check | What the result means | Safe next action |
|---|---|---|---|
| Title and body text | Reopen the same post in a second editor tab; compare the exact changed paragraph | The stored edit may differ from the still-open working copy | Keep the unsaved copy and repair the save request before replacing content |
| Publication status | Check Draft, Pending or Published in the reopened editor, then open the public URL while logged out | A successful preview does not prove publication | Confirm the intended status before telling anyone the page is live |
| Featured image and other post fields | Inspect each changed field in the reopened editor | One field can persist while another fails | Retry only the missing change after the cause is known |
| SEO title and description | Check the SEO plugin fields; after a successful save and cache refresh, check the public page source | Stored metadata and the served snippet fields are separate checks | Preserve the previous fields and verify the final output |
| The public page still looks old | Compare stored content with a logged-out clean URL and a cache-busted URL | If the stored edit is current, delivery may be stale | Follow the changes-not-showing checks before rewriting the post |
A newer “last modified” time is useful context, but it does not prove every field changed. Likewise, a revision is a recovery aid rather than a substitute for checking the current saved post. WordPress’s block-editor documentation describes the publishing and editing controls; use the actual post status as your starting point.
Find the request that failed
If you are comfortable using browser developer tools, open the Network panel, select Fetch/XHR and leave it recording. After preserving the edit, make one controlled save attempt. Find the request associated with that attempt and note its URL path, HTTP status and response type. Your host or developer can do this for you.
Look at the failed save request itself. Loading the public /wp-json/ index proves that one read request works; it does not prove that an authenticated write to a particular post succeeds.
| Response evidence | Possible layer | Who should check it | Stop rule |
|---|---|---|---|
| 401, a login page, or an authentication-related response | Expired session or authentication handling | The site administrator; sign in again in a fresh tab after preserving the edit | Keep session cookies and authentication headers private |
| 403 or a firewall/challenge page | Permissions, a security plugin, hosting protection or CDN rules | The owner of that protection, using the request time and matching logs | Leave the firewall active; correct only the confirmed rule |
| 404 or a redirect to an unrelated HTML page | Routing, redirect rules, domain configuration or a missing endpoint | The host or developer who owns routing | Preserve permalink and server rules until routing is understood |
| 500 or another server error | PHP, a plugin, theme or server failure | The maintainer, with the matching private error log | Stop repeated saves and preserve the first useful error |
| 200, but HTML or stray text appears where JSON is expected | Unexpected output, a challenge or another response substitution | The developer, comparing response content with server/plugin evidence | A 200 status alone does not prove a valid save |
These are investigation directions, not diagnoses from status codes alone. For example, a 403 does not identify which rule blocked the request. The request path, response and matching logs establish the next owner.
Repair one cause and repeat the same save
Begin with the least disruptive confirmed cause. If the session expired, sign in again, reopen the post and reapply only the missing edit from your private copy. If a protection rule blocked the request, ask its owner to inspect that exact event and correct the narrow rule when justified.
If the failure follows a plugin or theme change, preserve the installed version and recent error evidence. Use a current backup and staging environment to isolate the responsible component. Avoid deactivating every plugin on a live business site: forms, access controls and other features can depend on them.
Do not disable the REST API as a fix. WordPress’s REST API guidance warns that doing so breaks admin functionality that depends on it. Switching editors can hide the symptom without establishing why the original save failed.
After the repair, repeat the original edit once. Reopen the post, compare the changed fields and inspect the logged-out public result. If the failure returns, stop and retain the new response instead of adding more unconnected changes.
What to send your host or WordPress developer
A useful private handoff contains the affected post ID or URL, the editor used, the failed-save time and timezone, the request path and status, which fields persisted, and the last relevant plugin, domain or hosting change. Include the exact visible error and the outcome of one controlled retry.
Share logs through an agreed private channel. A raw network export can contain cookies, authorization headers, nonces, private content and personal data. Ask the recipient for the minimum evidence they need and remove sensitive values before sharing a screenshot or extract.
Professional help makes sense when saves keep failing, different fields persist inconsistently, the response contains a server error, or you cannot safely inspect the protection and routing layers. Webless’s WordPress development and repair service is the relevant route for investigating the failing request, fixing the responsible component and checking that the intended page changes reach visitors.