Preserve the current edit, verify the existing record and diagnose the exact save request before changing a responsible setting. Confirm persisted readback and publication status separately.
When WordPress reports “Updating failed” or “The response is not a valid JSON response,” preserve your unsaved work before reloading or changing settings. Then investigate the particular save request and verify the existing post. The error message alone does not establish which content or settings reached the server.
This guide uses official WordPress and browser documentation checked on 13 October 2026. It separates recovering the current edit from diagnosing the save route. No production setting, account, post or security rule was changed for the guide.
Protect the current edit first
Keep the affected editor tab open. Copy the title and current body to a private local document, along with any important unsaved excerpt or custom-field values. Confirm the copy contains the newest sentences rather than an earlier published version. Do not put confidential content into a public paste service.
The WordPress Block Editor documentation describes copying all content and switching between Visual and Code editor views. Preserving block markup can help retain structure, but do not assume that a body copy includes every plugin panel, taxonomy, image selection or publishing setting.
Record the post’s identity, current draft or published state, error wording and time. If a colleague is editing it too, coordinate before overwriting their changes. Recovery should not turn an uncertain save into an accidental duplicate or replace someone else’s newer edit.
Check what was saved before repeating an action
After preserving the edit, use a separate normal administration view to find the same existing post. Compare its saved title, body and relevant fields with your copy. Check publication status and scheduled time separately. Keep the original unsaved tab available until the comparison is complete.
WordPress revisions and autosaves provide another recovery route when a suitable saved record exists. An autosave is separate from the published post; its presence is not proof that the latest edit became public. Our article recovery guide covers that comparison in more detail.
If the post is already live, inspect its actual public page rather than pressing Publish again. If the intended changes are absent, retain the copy while investigating. Do not create another post with the same content simply to bypass a save error.
Understand why JSON appears in an editor error
The WordPress REST API exchanges structured data, including content used by administration features. A save involves more than the visible editor: the browser request must reach the correct route, receive appropriate authorisation and return a response the client can understand.
Mozilla’s JSON.parse reference explains that invalid JSON text cannot be parsed as the expected data. A returned login page, HTML error or unexpected output is therefore different from a valid JSON response describing a rejected operation. The wording is a symptom to investigate, not a diagnosis of a particular plugin.
The Posts API reference documents content, status and other post fields. A public read of an API route does not establish that your authenticated account can update a particular post through the editor’s actual request.
Inspect one failed request without sharing credentials
With the work preserved and a controlled retry appropriate, open the browser’s Network panel before the operation. Identify the request associated with that save, rather than an unrelated image or analytics failure. Chrome’s Network reference documents request headers, status, response and timing inspection.
| Observed evidence | Investigation direction | What to avoid assuming |
|---|---|---|
| Login or challenge HTML | Session, redirect or intermediary response | That the article’s text has invalid JSON syntax |
| 401 or 403 response | Authentication, permission or security refusal | That every refusal has the same cause |
| 404 on the save route | Requested address and routing | That changing every permalink is necessary |
| 5xx or an empty interrupted response | Server failure and relevant logs | That another click safely completes the same operation |
| Readable JSON with an error | The specific error code and message | That all JSON-related notices are parsing failures |
Keep the method, route path, status, response kind and time in a private diagnostic record. Network details can contain cookies, authorisation values, nonces and article content. Do not paste a complete request, raw export or screenshot of credentials into a public support thread. Use an approved private support route for necessary evidence.
The JavaScript console and network guide covers the wider browser investigation. This task is narrower: identify the save’s response and its relationship to the saved post.
Resolve session and permission issues through the normal login
WordPress REST authentication guidance explains cookie-based authentication inside WordPress, the required request nonce and the user’s action-specific capability. Being able to read a page does not establish permission to edit every post.
If the normal session has expired, preserve the edit and reauthenticate through the known WordPress login. Then reopen the existing post, compare its saved state and merge only the missing intended changes. Avoid copying nonce values between sessions or inventing manual authentication headers.
Ask the administrator to review a genuine role or ownership issue. Do not grant every editor administrator access or make private API content anonymous merely to remove a refusal. A working correction should keep the intended permission boundary.
Investigate addresses and routing without a blanket reset
If the request reaches an unexpected hostname, protocol or path, compare the intended configuration with the observed redirect. WordPress General Settings distinguishes the application address from the public site address; installations in their own directory can legitimately differ.
Do not force both settings to the same value without understanding the installation. A domain or HTTPS correction needs the responsible administrator and a recovery route, rather than trial changes that can disrupt login.
The Permalinks documentation explains rewrite configuration and that visiting the screen triggers a rewrite-rule flush. Treat that as a scoped administrative change when routing evidence warrants it, not a harmless ritual for every editor error. Preserve existing URL structure and unrelated server rules. The WordPress routing guide covers the separate 404 investigation.
Correlate server and integration evidence
For unexpected output or server failures, give the maintainer the route, time and affected action. Compare the corresponding error and access records rather than guessing from the browser banner. The website logs guide explains a useful correlation record.
WordPress debugging documentation distinguishes logging from displaying warnings to visitors. A maintainer should collect necessary evidence safely, avoid publicly exposing logs or debug output and restore the intended diagnostic settings afterwards. Hiding a warning is not the same as fixing the code that produced it.
If a security layer refused a legitimate edit, request a review of that exact event. Do not leave the firewall disabled or weaken validation across the site. If a plugin interaction is suspected, reproduce it in a protected test copy and use the plugin dependency audit before changing a component with other responsibilities.
Verify the repair with an existing record
The REST API FAQ warns that disabling the API breaks dependent administration functionality. Replacing the editor or disabling the API can hide the original problem while leaving its cause unresolved.
- Keep the recovered title, body and important settings until verification is complete.
- Apply the authorised correction to the identified cause.
- Open the existing intended draft and make one small, reversible verification edit.
- Save once, wait for a clear outcome, then reopen and compare the saved value.
- Verify relevant metadata, status and preview separately from the success message.
- Confirm any intended publication on its real public URL without creating another copy.
Record the observed cause, correction and remaining uncertainty. A successful request and persisted readback support the save result; publication still needs its own deliberate decision. Once that boundary is clear, merge the preserved work and continue editing through the normal workflow.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: Block EditorChecked Visual/Code editor views and copying post/page content through native tools.
Limits: A body copy does not imply complete custom-field/settings backup; no actual editor session or copy was tested. - WordPress: RevisionsChecked Saved revisions and autosaves are distinct records; autosaves do not overwrite published content.
Limits: No latest unsaved edit, available revision or successful recovery is guaranteed. Existing post data was not accessed. - WordPress: REST API HandbookChecked Structured content exchange and the API role in WordPress applications and administration.
Limits: A general explanation does not diagnose the reader request or prove authenticated write access. - Mozilla: JSON.parseChecked Invalid JSON text cannot be parsed as the expected data, supporting distinction between parse failures and readable API errors.
Limits: No saved-state outcome is inferred from the banner. HTML/challenge examples are diagnostic possibilities, not observed causes. - WordPress REST API: PostsChecked Post content, status and related fields are separate parts of the API record.
Limits: No manual API request, credential creation or direct database editing is prescribed. Reading a route does not establish permission to update a post. - Chrome DevTools: Network referenceChecked Request/response, status, timing and header inspection for the actual operation.
Limits: No network trace was collected. Credentials, cookies, nonces and private content must not be copied to public diagnostics. - WordPress REST API: AuthenticationChecked Native cookie authentication, request nonces and action-specific user capabilities.
Limits: No nonce copying, header replay, anonymous private access or broad permission escalation is recommended. - WordPress: General SettingsChecked WordPress application address and public site address differ in purpose and can legitimately differ by installation layout.
Limits: No unobserved address mismatch is asserted and no trial URL change is performed. - WordPress: Permalinks settingsChecked Permalink/rewrite responsibilities and the fact that visiting the settings screen flushes rewrite rules.
Limits: A rewrite flush is an administrative change, not a guaranteed universal JSON fix. No permalink or server-rule reset is provided. - WordPress: DebuggingChecked Diagnostic logging differs from public debug display; warnings and errors need scoped maintainer investigation.
Limits: No production debugging enabled, log exposed or output suppressed as a substitute for correcting its cause. - WordPress REST API: Frequently Asked QuestionsChecked Disabling the API breaks administration features dependent on it.
Limits: No API-disabling workaround, replacement-editor cure or security bypass is endorsed.