The affected list uses the built-in Microsoft Lists or SharePoint modern form, not Power Apps or a custom editor.
What this SharePoint form failure looks like
Blank value will not commit
Users can change text normally, but when they remove all text from a field, the form does not save that blank value back to the list item.
Grid View behaves differently
The same text field can still be emptied in Grid View, which helps isolate the problem to the modern form experience.
The behavior changed without a list redesign

Clearing text fields had worked normally before the issue appeared.
Now fails consistently
After the change, users could no longer save empty text fields in the form, even though other edits still went through.
No local trigger identified
The evidence does not show a form customization, field rule, or permissions change that would explain the sudden shift.
Exact checks that rule out common list settings
-
Column requirement was checked
The affected text columns were not marked as required, so the form should have accepted a blank value.
-
Permissions were tested
Even temporary Full Control access did not restore the ability to clear the field in the form.
-
Browser cleanup was tested
Deleting browser cookies did not solve the problem. In one case, it caused the list owner to start seeing the same failure too.
Which entry points fail and which one still works
Where the problem appears
| Location | Result when clearing a text field | What it suggests |
|---|---|---|
| Standard modern edit form | Blank value does not save | The modern form is affected |
| Direct item page such as DispForm.aspx?ID= |
Same failure appears | The issue is not limited to one navigation path |
| Grid View | Blank value still saves | The list can still accept empty text values outside the form UI |
A direct item page in this pattern was specifically affected: https://. That matters because it shows the failure is tied to the form behavior itself, not only to one list view.
Why the cookie test points away from list configuration
Cookie-related observation
Before cookies were cleared
The list owner could still empty a text field in the edit form while other users could not.
After sharepoint.com cookies were removed
The same owner account began failing in the same way, which supports the idea of a Microsoft-side change rather than a broken column setting.
Practical conclusion: if Grid View can still clear the field and the modern form fails across users after cookie resets, there is no source-backed evidence of a local fix inside list settings alone.
The issue was reported across multiple tenants
Confirmation from another user
-
A separate report confirmed the same behavior on all tested tenants.
-
That broad scope makes a tenant-specific list misconfiguration less likely.
-
For troubleshooting, treat this as a service behavior affecting the modern form until Microsoft confirms a platform fix or root cause.
Use WPS Office as a Free Microsoft Office Alternative
Recommended next step
Confirm the exact symptom in the modern form
Open the Microsoft List item in the standard modern edit form. Delete all text from a non-required text column, save the item, and confirm that the blank value does not commit.
Check the same item through its direct page
Open the item using its direct SharePoint page pattern such as /Lists/. If the blank value still will not save, the issue is not limited to one list view.
Use Grid View as the practical workaround
Edit the same row in Grid View and clear the text field there. If Grid View saves the blank value, you have a working temporary path while the modern form issue is investigated.
Open a Microsoft 365 admin support request
If you are an admin, create a case through the Microsoft 365 admin center using the support guidance at Get support - Microsoft 365 admin. If you are not an admin, identify your tenant admin using How do I find my Microsoft 365 admin? and ask them to submit the case.
Final verification before you close the case
Retest the same non-required text column in the modern edit form after Microsoft reviews the service-side logs or announces a fix. The issue is resolved only when the form itself saves a truly blank value, not just Grid View.
Important limitation: this issue is tied to Microsoft Lists and SharePoint Online service behavior. WPS Office cannot repair Microsoft-side tenants, cloud forms, admin controls, licensing, or service logs. It can still be a useful free companion for local DOCX, XLSX, PPTX, and PDF work when you need a lightweight editor with a familiar ribbon UI, PDF tools, and WPS AI features for drafting summaries or cleanup notes. Compatibility is best for common Office formats, but SharePoint form logic and tenant-side controls remain Microsoft-managed.

Fix SharePoint List Forms That Will Not Save Blank Text Fields FAQs
Does clearing sharepoint.com cookies permanently fix this Microsoft Lists problem?
No. In the observed behavior, deleting cookies actually made the issue appear for an account that had still been working. It is a useful diagnostic check, not a confirmed repair.
What should I verify before opening a Microsoft 365 admin support case?
Confirm the field is not marked Required, test the same item in the standard form and Grid View, note whether the direct item page also fails, and record whether the behavior changes after deleting sharepoint.com cookies.
If the text column is not required, why can’t users clear it?
A non-required setting normally allows blank values, so this symptom points beyond ordinary column configuration. The reproduced reports and Microsoft response indicate a likely server-side SharePoint or Microsoft Lists problem instead.
Does clearing SharePoint cookies fix the problem permanently?
No source-backed permanent browser fix is established. In the reported case, deleting sharepoint.com cookies actually caused the issue to appear for an account that had still been able to clear text fields before.




