Visitors Can Edit Files Despite Read Permission: Root Cause and Fix

You set a SharePoint site group or permission level to Read, but visitors can still edit files. This problem often occurs because SharePoint permission inheritance is broken or because the site uses Microsoft 365 group membership that grants additional access. The root cause is that user permissions can stack from multiple sources, such as direct site permissions, item-level permissions, or membership in a Microsoft 365 group that has higher access. This article explains why this mismatch happens and provides a step-by-step fix to restore true Read-only access.

Why Visitors Can Edit Files With Read Permission

SharePoint permissions are additive. A user’s effective permission level is the highest permission they receive from any source. If you assign a user the Read permission level on a site, but that user is also a member of the site’s Microsoft 365 group that has Edit or Full Control permissions, they will have Edit access despite the Read assignment.

Another common cause is broken permission inheritance. When a site, library, or folder has unique permissions, a user might have been granted Edit access directly on that item. The parent site’s Read permission does not override the item-level Edit permission. Additionally, sharing links that grant Edit access can bypass site-level permission settings.

Permission Sources That Override Read

A user can gain Edit access from any of these sources:

• Direct membership in the site’s Microsoft 365 group
• Unique permissions on a subsite, library, folder, or file
• Sharing links with Edit permission sent to the user
• Security group membership that grants Edit access
• Azure AD role assignments, such as Global Administrator or SharePoint Administrator

Steps to Identify and Fix the Permission Override

Follow these steps to determine why a user can edit files and to restore Read-only access.

1. Check the user’s effective permissions
   Go to the site where the issue occurs. Select Settings gear > Site permissions. Choose Check Permissions. Enter the user’s email address. Review the results to see which permission levels the user has and the source of each permission. If the user has Edit or Contribute from any source, that explains the problem.
2. Remove the user from the Microsoft 365 group
   If the user is a member of the site’s Microsoft 365 group, go to Microsoft 365 admin center > Groups > Active groups. Select the site group. Under Members, remove the user. The user will lose Edit access from that group. The user will still have Read access if assigned at the site level.
3. Reset unique permissions on subsites, libraries, or items
   If the Check Permissions tool shows a permission source as a specific item, navigate to that item. Select Settings > Library settings (or List settings) > Permissions for this document library. On the ribbon, select Delete Unique Permissions. Confirm the action. The item will inherit permissions from the parent site.
4. Revoke sharing links that grant Edit access
   Go to the library or file. Select the three dots (More) > Manage access. Under Links, find any link that has Edit permission. Select the three dots next to that link and choose Remove link. This stops users from accessing the file through that link.
5. Verify the site’s permission inheritance chain
   Go to Site settings > Site permissions. In the ribbon, select Manage parent. This shows the parent site. If the parent site has unique permissions, check those permissions as well. Restore inheritance from the parent site if needed by selecting Inherit Permissions in the ribbon.

If Visitors Still Have Edit Access After the Main Fix

User is a member of a security group with Edit access

A user might be in a security group that has been granted Edit permissions on the site. Use the Check Permissions tool again. If the source is a security group, remove the user from that group in Azure AD or SharePoint. Alternatively, change the security group’s permission level to Read on the site.

User has an Azure AD role that grants elevated permissions

Global Administrators and SharePoint Administrators always have Full Control over all sites. You cannot reduce their access through site-level permissions. If the user needs only Read access, remove their Azure AD role. Go to Microsoft 365 admin center > Users > Active users. Select the user. Under Roles, uncheck the elevated role.

Inheritance is broken on a subsite

If the site has subsites with unique permissions, the user might have Edit access on a subsite even if the parent site has Read. Check each subsite’s permissions using the Check Permissions tool. Reset inheritance on the subsite or remove the user’s direct Edit permission on that subsite.

Read Permission vs Edit Permission: Key Differences

Permission Level	Read	Edit
View files	Yes	Yes
Download files	Yes	Yes
Edit files	No	Yes
Delete files	No	Yes
Upload new files	No	Yes
Create new folders	No	Yes
Change site settings	No	No

The table above shows that Read permission allows viewing and downloading only. Any ability to edit, delete, or upload indicates that the user has a higher effective permission level. Use the steps in this article to identify and remove the source of that higher permission.

You can now diagnose and fix the situation where visitors can edit files despite having Read permission. Use the Check Permissions tool first to find the exact source of the override. Next, remove the user from the Microsoft 365 group or reset unique permissions on the affected items. For persistent issues, review Azure AD roles and security group memberships. A practical tip: after making changes, run the Check Permissions tool again to confirm the user’s effective permission level is now Read.