Share Links give recipients a way to work with selected files without becoming Files.com users. Their access comes from the Share Link's configuration, rather than the recipient's folder permissions. This makes sharing convenient for external collaboration, but also means that managing an employee's account and managing links they distributed are separate responsibilities.

Choose a link's access requirements according to the information being shared and the relationship with its recipients. A public download, a password-protected delivery, and a delivery restricted to invited mailboxes establish different expectations about who can use the link and what its activity records tell you.

Choosing Recipient Requirements

A basic Share Link can be used by anyone who has its URL. Asking visitors to register records the details they enter; it does not verify that those details identify the person using the browser. Sending invitations associates activity with particular invitation URLs, but the invitation can still be forwarded.

Access Control requires an invitation and limits how its URL starts a browser session. A shared password adds a secret recipients must know. Email-based one-time passwords check access to an invited mailbox. Password protection and email-based one-time passwords are alternative settings; they cannot be enabled together on one Share Link.

Use email-based one-time passwords when mailbox verification is required. Use a password when a shared secret fits the delivery process. Neither a shared password nor access to a shared mailbox establishes a particular person's identity. If recipients need continuing, individually managed access with user-level controls, consider user accounts instead of treating a Share Link as an account substitute.

Ownership and Shared Content

A user needs Share permission on a folder to create links to its contents. A Share Link can belong to a user or a group. Every member of an owning group can manage that group's links, so adding a person to the group also delegates responsibility for its existing shares. Links created with a site-wide API key have no user owner and are managed by Site Administrators.

The link's scope cannot exceed the creator's Share permission when it is created. With non-recursive Share permission, sharing a folder includes no subfolders. That limit applies to every visitor operation, including previews; a preview does not provide a separate route into content outside the share.

Sharing requires Share permission from every Site involved. For files in a Files.com Remote Server mount, both the creator and the paired API key need Share permission on the folders being shared, each on its own Site. The creator's permission alone does not authorize sharing the other Site's files.

A link to live files follows changes to the shared content. New files added within its shared scope can become available through the existing link. A Snapshot Share Link instead delivers a fixed copy. Choose live sharing for an ongoing exchange and a snapshot when recipients should receive a particular version of a delivery.

A Guest Share Link cannot include Host files from a Connected Site under _/Sites/<host-site-id>. Sharing requires Share permission from every Site involved, and a Host Partner can never hold Share. Creating a link or changing its paths or permissions to include Host files fails with the same permission error as sharing a folder without Share permission, including for Guest Site Administrators.

The Guest's Share Links to its own files follow the Guest Site's sharing settings, including expiration, password, registration, recipients, one-time passwords, notes, and watermarks. The Host's sharing settings do not apply to those links. Access Across Sites and Storage explains the connection's boundaries.

Visitor Capabilities

The link's allowed actions bound what visitors can do with the shared contents. Upload-only links and links allowing both uploads and downloads let visitors add files, but not replace existing ones. If an uploaded filename is already in use, Files.com renames the upload and keeps both files, regardless of the upload client, its requested overwrite behavior, or the site's overwrite setting. Replacing an existing file is a modification and requires Full access.

Full access also lets visitors rename, move, and delete shared contents. It does not grant folder administration: visitors cannot create Folder Settings or copy them with a folder, because copying settings requires folder administration at both the source and destination. Moving a folder within native storage, however, retains its settings. A Full access link above a configured folder, including a Remote Server Mount, therefore lets visitors relocate that folder with its settings. Reserve Full access for recipients trusted to manage the shared contents.

Upload-only visitors and Inbox uploaders receive confirmation using only the filenames they submitted, both in upload responses and receipt emails. They do not receive the stored name assigned after a name conflict or automatic rename, the folder's stored site path, or the Share Link's internal name or note. This confirms receipt without exposing other submissions or the site's folder organization. Visitors with download-and-upload access can see stored filenames because that access permits listing the shared contents.

A preview still displays file contents to the recipient, who can capture what they see. Removing a download button does not make visible information unreproducible.

Watermarked previews are supplied only to the visitor for whom they were generated, and their preview URLs never return the unwatermarked original. Text watermarks can include the visitor's registration details to associate a redistributed preview with that registration. Normal file downloads do not include the automatic watermark; choose previews-only access when recipients should receive only watermarked previews.

Invitations and Identity

Each recipient receives a different invitation URL. Activity through that invitation is associated with the invited email address, including when someone else opens a forwarded copy. The address in the activity record identifies the invitation used; the invitation alone does not establish who is using the browser.

Email-based one-time passwords add a check that the visitor can obtain a code sent to the invited mailbox. This is useful when access must depend on control of that mailbox as well as possession of the invitation. A shared mailbox or a code passed to another person still does not establish an individual person's identity.

Invitation Reuse Across Browsers

With Access Control enabled, the browser that first opens an invitation establishes a session. Opening the same invitation in another browser, another device, or a private browsing session requires a replacement invitation. Files.com sends the replacement to the invited email address and invalidates the original invitation for new sessions. Replacement emails are limited to one per recipient per Share Link every 15 minutes.

The existing browser session keeps its access. Replacing an invitation changes how someone starts a session; it does not end sessions that already exist. Each recipient's invitation is handled independently, so opening one recipient's invitation does not invalidate another recipient's invitation.

For example, if Morgan forwards an unused invitation to Lee and Lee opens it first, Lee establishes the first session. Activity is associated with Morgan's invited address. When Morgan opens the same invitation in a different browser, Morgan needs the replacement sent to their mailbox. Requiring an email-based one-time password adds the mailbox check before Lee can access the share.

Expiration and Visitor Limits

Expiration sets the period during which a delivery remains available. Site settings can cap how far into the future a user sets a link's expiration; a shorter site-wide limit can also expire existing links. Snapshot Share Links have a maximum lifetime of 60 days. A publish date controls when access begins.

Visitor limits count each new visitor once using browsing data rather than verified individual identities. Returning from the same browser does not count again while that browsing data is retained. Downloads, previews, and uploads do not increase the count. One person using different browsers or devices can count as several visitors, while people sharing the same browser's browsing data can count as one. Use recipient requirements when you need to control who may receive the files.

Once the count reaches the limit, new visitors see the unavailable page. Visitors already counted keep the access the link allows until it expires or is revoked. Lowering the limit to or below the current count blocks new visitors without ending existing visitors' access. To end that access, revoke the Share Link or set an expiration date.

Site-wide sharing controls have different effects on existing links. Disabling the creation of Share Links stops new links but leaves existing ones available. Requiring one-time passwords for new links does not add verification to previously created links. Review and revoke existing links separately when changing your sharing policy.

Changes to Existing Access

Enabling Access Control on an existing Share Link restricts new access without ending existing visitor sessions. To end access for all visitors, revoke the Share Link. A new Share Link can then use the required password or recipient restrictions.

Revocation cannot retrieve files already downloaded or content already loaded in a browser. File requests already authorized through temporary URLs also have their own expiration rules. Those limits are separate from the invitation and Share Link lifetimes.

Access After Changes to the Owner's Account or Permissions

Removing an owner's folder permissions does not revoke links they already created. Disabling or deleting the owner also leaves their links available by default so deliveries and shared business workflows can continue. The optional automatic-revocation setting applies when a user is disabled or deleted; it does not turn a folder-permission change into revocation.

An offboarding review therefore includes the person's links and any groups that own links, as well as their account. Share Link Ownership and Management explains how to retain a needed business delivery under suitable ownership or revoke a link whose purpose has ended.