Choose a suitable attachment or approved sharing route, review the actual file and all effective permissions, then test the intended recipient task and later access removal with harmless samples.
When an attachment is too large, replacing it with a cloud link solves only the message-size problem. You still need to check which file the link opens, who can access it, whether the recipient can download it and what happens when the work ends.
Use an ordinary attachment for a suitable small file when both mail systems accept it. Use a controlled sharing route when the file is large, needs collaborative updates or needs later access management. The choice should follow the recipient’s task and the information involved, not merely the easiest button in the compose window.
Check the actual sending and receiving limits
Attachment limits are not universal. Gmail’s current attachment documentation gives a 25 MB limit for personal accounts and explains that Workspace administrators control work/school limits. It also describes replacement with a Drive link when the total exceeds the applicable limit. Another recipient’s mail system may have a different constraint.
The file’s disk size is not necessarily the transmitted message size. MIME base64 encoding expands encoded binary data by about one third, before other message structure is counted. As a simple arithmetic illustration, 18 MB of raw data becomes roughly 24 MB of base64 data; this is not a promise that any particular mail server accepts it.
Check all files together and read the rejection reason if sending fails. A temporary delivery error, a full mailbox and a size rejection need different responses. Use the bounce diagnosis guide instead of repeatedly resending the unchanged message.
Choose access based on the material
| Material and task | Sharing direction | Important verification |
|---|---|---|
| A brochure intended for anyone | A deliberately public download or public sharing link | Correct edition, working download and no private material included |
| A client-specific document | Restricted access for intended recipients | Authorised access works; an unrelated identity does not gain access |
| A document needing comments | Comment permission if supported and sufficient | Recipients can comment without unnecessarily editing the source |
| A package requiring local installation or processing | An approved download route | Download permission, expected file type and a trusted source |
“Anyone with the link” is a broad access decision, not a synonym for private. A link can be forwarded. A public brochure and a customer report should not inherit the same sharing policy simply because both are PDFs. For downloads intended for your website’s public audience, use the separate public PDF workflow.
Prepare the right file before granting access
Confirm that the upload completed and that you can open the stored file. Check its name, edition, contents and format, including comments, hidden sheets or extra files that should not be shared. Use a harmless sample to test a new workflow before transferring real confidential material.
Prefer a specific file or a dedicated project folder over an entire working directory. Make the intended deliverable explicit: for example, a final export for download versus a live document that will continue changing. If you send several files, identify the required ones and keep private drafts outside the shared scope.
Gmail’s Drive-attachment guidance explains that sharing settings determine whether recipients can open linked files. Copying a URL into email does not automatically grant the permissions you intended. Review the sharing dialogue rather than assuming the recipient list and file-access list are identical.
Review existing permissions, including the parent folder
In Google Drive, sharing roles and general access distinguish restricted access from anyone-with-link access and viewer, commenter and editor roles. A viewer can ordinarily download by default unless the owner applies supported restrictions. Choose the least access that still completes the agreed task.
Inspect existing people and groups too. Adding one recipient does not remove others who already have access. Folder permissions can broaden access beyond what a file’s link settings suggest. Do not rely on the fact that you emailed the URL to only one person.
The limited-access folder guidance describes using a deliberately limited subfolder when only selected people should see its contents. Check your account’s current sharing model and available controls. Moving the document into a broadly shared folder can change the effective audience, so include location changes in your review.
Distinguish specific-person access from an editable public link
OneDrive’s sharing documentation separates specific-person and existing-access links from broader link types. It also warns about the scope of editing a shared folder. Confirm whether the recipient should view, comment or edit, and inspect the selected permission rather than trusting a default.
Expiry dates, passwords and download controls depend on the account, link type and organisation settings. Do not promise those features before checking their availability. A separately communicated password can provide an additional gate where supported; sending the password beside the link removes that channel separation and does not resolve compromised recipient accounts.
Microsoft’s external-sharing guidance explains that recipient experience varies with the account and selected settings. Work/school policy may block outside sharing. Resolve that with the authorised owner or administrator rather than making a restricted business document public to bypass the restriction.
Test both allowed and disallowed access
- Use a sample file containing no sensitive data and confirm the owner, folder and effective permissions.
- Grant access to an agreed test recipient, with the role needed for the task.
- Have that recipient open the exact link using the intended identity, without the owner’s signed-in session masking the result.
- Verify preview and download separately if a local copy is required.
- Check with a controlled identity that lacks permission. Restricted material should not become available merely because that identity has the URL.
- Remove the temporary grant and verify the expected later denial, while accounting for any other existing access.
A private browser window can reveal that a file requires authentication, but it cannot prove that the intended recipient’s account has permission. Conversely, a successful owner preview proves little about someone else’s access. Record the identity and role used for each result without storing passwords or live sharing tokens in a public report.
Give recipients enough context to open the right item
Write a short message identifying the file, purpose, expected format and any agreed deadline. Say whether it is a live working document or a fixed deliverable, and whether the recipient needs to sign in with a particular address. Use a meaningful link label rather than an unexplained shortened URL.
If access is denied, first compare the invited address with the recipient’s active account and check the file’s current permissions. An alias, personal account or other organisation account may not be the intended identity. Do not approve an unfamiliar access request merely because it arrives shortly after your email.
If recipients need to send files back through your website, that is a separate collection route with storage and deletion responsibilities. Use the contact-form upload workflow instead of opening an editable folder to every visitor.
Understand what revocation and download restrictions cannot undo
When the collaboration ends, review grants, general links and group membership. Remove access through the provider’s controls and verify the result with the test recipient. Do not assume deleting the original email revokes the stored file.
Google’s sharing restriction guidance explicitly distinguishes supported download/copy controls from other ways content can be shared. Revocation cannot retrieve copies already downloaded, screenshots or information a recipient has retained. Describe it as stopping future authorised access through that route, with those limits.
Retain your authoritative copy and any required delivery record according to your own policy. A cloud sharing service is not automatically a complete backup, confidential-transfer certification or proof that the recipient read the document. Accept the workflow only when the intended person can perform the required task, unintended access is constrained and the end-of-access process has been checked.
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
- Gmail: Send attachmentsChecked Personal attachment limits differ from administrator-controlled Workspace limits and large totals may become Drive links.
Limits: The 25 MB figure is scoped to personal Gmail; no universal sender/recipient limit or actual delivery result. - RFC 2045: MIME transfer encodingsChecked Base64 expands binary data by about one third; message structure adds further overhead.
Limits: The 18-to-24 MB example is illustrative arithmetic, not a measured message or acceptance threshold. - Gmail: Send Google Drive attachmentsChecked Linked attachments require an intentional sharing setting for recipient access.
Limits: Copying a URL or composing a recipient list is not treated as proof of granted permission. - Google Drive: Share filesChecked Restricted versus anyone-with-link access, sharing roles, existing grants and inherited folder access differ.
Limits: Viewer download is default unless supported restrictions apply; no actual user file is inspected. - Google Drive: Limited-access files and foldersChecked Limited subfolders can separate a smaller audience from broadly shared parent material.
Limits: Account models and available controls require review; no automatic guarantee follows from a folder name. - Microsoft: Share files and folders in OneDriveChecked Specific-person, existing-access and broad links differ; editing scope, expiry, password and download options have account/link limitations.
Limits: No feature is promised on every plan and no bypass of organisational restrictions is recommended. - Microsoft: External or guest sharingChecked Recipient experience and external access depend on account and selected settings.
Limits: A logged-out window is not proof that the intended signed-in recipient has permission. - Google Drive: Stop, limit or change sharingChecked Supported sharing and download restrictions do not prevent every other form of content redistribution; parent grants remain relevant.
Limits: Revocation cannot retrieve downloaded copies or screenshots; no confidentiality or backup certification is claimed.