Home » AI & Digital Tools » Google Drive Sharing Permissions: Viewer, Commenter, Editor

Google Drive Sharing Permissions: Viewer, Commenter, Editor

Published:

Short answer: Choose Google Drive sharing permissions according to what the recipient actually needs: Viewer for reading, Commenter for feedback and Editor for changing the file. Check both named people and General access, inspect the containing folder and keep sensitive working material separate from public deliverables. A copied link does not by itself tell you who can open the file.

Unbranded folders with viewing, commenting, editing and lock symbols connected to people

Choose Google Drive sharing permissions by task

Google’s file-sharing guide distinguishes Viewer, Commenter, Editor and Owner for files in My Drive. A Viewer can read, a Commenter can add feedback and an Editor can alter the file. Downloading and further sharing are separate considerations, with owner controls and account policies affecting what is available. Shared drives have additional roles and should not be assumed to behave exactly like My Drive.

Recipient’s task Starting role Question before sharing
Read a finished document Viewer Is every page suitable for this audience?
Review and leave feedback Commenter Can suggestions meet the need without editing?
Maintain the working file Editor Who is responsible for changes and access?
Control the file as its owner Ownership decision Is a transfer genuinely intended?

Start by naming the task rather than the person. “Review the draft” often means feedback, while “maintain the final budget” means controlled editing. Granting Editor automatically because the recipient is trusted may create unnecessary responsibility for both parties. The useful permission is the one that enables the agreed work without opening unrelated material.

Write down where the recipient’s job ends. A designer reviewing text does not necessarily need to change a client roster in the same folder. A customer receiving a final proposal does not necessarily need access to all earlier drafts. A colleague helping for one meeting should not automatically become a permanent member of the entire project workspace.

Check named recipients and General access

Review the specific people or groups with access, then inspect General access. Google’s sharing guide distinguishes Restricted from access offered to anyone with the link. Work and school accounts may offer or restrict options according to organisation policy. Select the audience deliberately; do not make a file broadly accessible simply to remove one recipient’s request-access message.

A useful editorial rule is to share private working documents with identified recipients and prepare a separate file for broad distribution. This is a workflow recommendation, not a claim that every organisation must choose the same setting. The decision depends on the content, intended audience and approved information-handling rules.

Check the actual email address before sending an invitation. Similar names and autocomplete entries can lead to the wrong recipient. If an organisation uses multiple accounts, confirm which account the reviewer will use. Asking for the correct account is usually easier than repairing an invitation sent to somebody unrelated to the work.

A link and permission are different things

When somebody says “the link does not work”, distinguish an incorrect URL from insufficient access or the wrong signed-in account. Ask for the visible error without requesting a password or OTP. Confirm which file the link points to and whether the intended recipient is represented in the access settings.

If the recipient forwards a link, that action does not explain whether another person can open the file. Access depends on the file’s settings and relevant group, folder or organisation permissions. Treat the sharing dialog as the place to inspect the audience, rather than inferring privacy from the fact that you sent the URL in a private conversation.

Inspect the containing folder before relying on a file setting

Google’s folder-sharing guidance says that folder permissions are inherited by items inside. It also explains that a person with higher access to a parent folder cannot simply be given lower access to a contained file through an ordinary per-file change. For a more restricted subset, consult the limited-access folder approach.

This matters when a folder mixes public deliverables and private working material. An editor invited for one project may receive access to new files later added to that folder. Review the folder’s purpose before putting customer records, identification scans or internal notes inside it. Naming a subfolder “private” does not itself establish a permission boundary.

The limited-access guide describes restricted subfolders and explains who can manage them in My Drive and shared drives. It warns that named access and General access still matter. Use the actual controls available to the account and inspect the result; do not assume that hiding a folder from a list removes every other access path.

Create a structure that is easy to review

Consider separate locations for working material, review copies and final deliverables. Decide who needs each location before uploading documents. This organisational choice makes future checks easier because files serving different audiences are not mixed together. It also helps a replacement project owner understand why each group has access.

Keep an access note describing the folder’s purpose and responsible owner. Avoid putting confidential details in the note itself. Review it when a collaborator joins, a project ends or a file changes from internal work to a customer deliverable. The note is a reminder to inspect the live settings, not an alternative source of permission truth.

Use a simple sharing and review workflow

First, open the file yourself and remove material outside the recipient’s purpose. Inspect comments, attachments, hidden or secondary sheets and information copied from another project. Do not assume that a polished first page means the entire file is ready for the intended audience.

Second, choose the recipient and role from the agreed task. Third, inspect folder and broader access. Fourth, send the correct file or link with a short explanation of what the person should do. Fifth, check that the recipient can perform that task without exposing additional material. These are preparation steps for a human workflow, not a claim of an automated security audit.

For feedback, explain whether reviewers should comment, suggest wording or edit directly. Set one clear place for decisions so that changes are not scattered across email, copied files and several versions. A review can become confusing even when permissions are correct if nobody knows which copy is authoritative.

Original permission-review worksheet

Use this blank worksheet privately: “File purpose: [purpose]. Intended audience: [people or group]. Task: [read, comment or edit]. Selected role: [role]. General access: [current setting]. Parent folder: [location and inherited access]. Additional access paths: [groups or shared-drive roles]. Published version: [yes, no or unknown]. Review owner: [person]. Next access review: [date or project event].”

The worksheet is an original planning aid, not a screenshot or a record of a tested Google account. Complete it using the actual sharing dialog. Mark unknown items as unknown and resolve them before distributing sensitive material. Do not fill gaps from memory because a folder had a certain setting last month.

Change or remove access when the task ends

Google’s stop or change sharing guide describes removing a named recipient and changing General access. It also explains that inherited folder access can require a change at the folder level. Inspect all relevant access routes after a change rather than assuming a removed individual entry resolves access obtained through another group.

Record the purpose of a change and check its effect on legitimate collaborators. A project may contain a working document that another team still needs. Removing broad access without understanding the agreed handover can cause unnecessary disruption. Review the intended outcome first, then adjust the smallest appropriate scope.

Revoking access should not be presented as retrieving every copy previously seen or downloaded. Once information has been legitimately viewed or shared outside the file, the live permission setting cannot establish that every recipient has erased it. Minimise sensitive content before sharing rather than relying exclusively on a later removal.

Download controls and organisational restrictions

Google’s security-limitations documentation describes a view in Docs, Sheets, Slides and Vids showing restricted actions and whether the restriction comes from owner controls or organisation policy. Check it when downloading, printing, copying or sharing is unavailable. Do not try to bypass a workplace restriction by making an unmanaged public copy.

A disabled menu should not be advertised as an absolute guarantee against information disclosure. A recipient can still learn what they are allowed to view, and the wider handling process remains relevant. For confidential client or employee data, follow the approved account and organisation policy rather than treating a single interface checkbox as the complete protection.

Review Publish to web separately

Google’s publishing guide describes a separate published URL for Docs, Sheets and Slides. Depending on account settings, the audience can be broad or organisational. Stopping ordinary collaborator sharing and stopping web publication are separate actions. Inspect whether the file has a published version when auditing who can see its content.

Do not publish a workbook containing private material just because one chart needs to appear on a website. Prepare a separate audience-appropriate output and check what data it exposes. Review future updates too: the original working file may later receive information that was never intended for a public deliverable.

Sharing also affects workflows using connected digital and AI tools. Before making a document available to an app or colleague’s account, understand the intended destination and permissions. Our personal versus work Copilot privacy guide explains why account context matters, while our Google account passkey guide addresses the separate issue of sign-in security. Neither replaces a file-access review.

Frequently asked questions

Should every reviewer be an Editor?

No. Match access to the task. Feedback may need Commenter, while a maintained working file may need Editor. Check account-specific restrictions and responsibilities.

Does “Restricted” mean nobody else has access?

Review the complete sharing context, including named recipients, groups, parent-folder access and any published version. A label should not replace that inspection.

Can removing one person leave another access route?

Check whether access also comes from a group, folder or shared-drive role. The intended result should be confirmed against the actual context.

Is turning off downloads complete protection?

It is one control, not a guarantee that information already viewed cannot be disclosed. Prepare content for the audience and follow applicable organisational rules.

Final action checklist

Review the content, identify the audience, choose the role, inspect General access and check the folder. Confirm the correct file and account, explain the review task and inspect published versions separately. Revisit access when the project changes. Good Google Drive sharing permissions connect the recipient’s actual job to the information they need.


Author: Ajit Naskar
Publication date: 8 October 2026
Updated: 8 October 2026
Last verified: 8 October 2026
Correction history: First publication; no corrections.

Features, labels and restrictions vary by account and organisation. Follow applicable workplace policy; this guide is independent and not endorsed by Google.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *