What you are actually controlling
Restricting a Figma link is two decisions, not one. The first is who the link is for — anyone with it, only people you invite, or your organization or workspace, where those options exist on your plan. The second is what those people can do once inside: view or edit. Treating a link change as a complete privacy fix usually means one of these was overlooked.
A third route sits outside the link entirely: access inherited from a team or folder the file lives in. Someone can open the file without appearing on any invite list you wrote.
Figma sharing separates the link audience from view or edit permissions, with organization and workspace options depending on plan. Source
File access can be inherited from a team or folder, so the list of individually invited people does not describe every access route. Source
Step 1: Record the current state before changing anything
Open the file’s Share settings and write down what you find, rather than editing as you go. You want a baseline you can compare against afterwards.
- Link audience: which option is selected — anyone with the link, only invited people, or an organization/workspace setting. Note the exact label shown to you.
- Link role: whether the link grants view or edit.
- Named people: who is individually listed, and with which role.
- Location: which team, project or folder the file sits in.
If a setting you expected is missing, that may be a plan or workspace-policy difference. Record it as unverified rather than assuming it does not exist.
Step 2: Inspect inherited access, not just the invite list
Before concluding the file is private, check the container. A file inside a team or folder can draw its access from that team or folder, so the individual invite list is only part of the picture.
Practical checks:
- Identify every team, project or folder the file belongs to.
- For each one, ask who is a member and what role they hold there.
- Compare that membership against the people you expected to have access.
- Note anyone whose access comes only through membership, not through an invite.
Inherited access is one possible explanation when a teammate can still open a restricted file. Check the permissions in your own workspace before deciding what caused it.
Step 3: Build an access table
An access table makes the routes visible and gives you something to review with the file owner or workspace admin. The example below is hypothetical, not a record of any real workspace.
| Route | Who it covers | Role | Set where | Reviewed? |
|---|---|---|---|---|
| Link audience | Anyone with the link | View | Share settings | Yes |
| Individual invites | Two named collaborators | Edit | Share settings | Yes |
| Team membership | Everyone in the design team | Inherited from team | Team settings | Needs admin check |
| Folder | Project folder members | Inherited from folder | Folder settings | Needs admin check |
The value is in the last column. A route you cannot inspect from the file itself is a route you have not yet restricted.
Step 4: Change the link audience and role deliberately
With the baseline recorded, adjust the link audience and role in Share settings. Two cautions:
- Changing the link does not necessarily remove access that arrives through team or folder membership. Those entitlements are governed where they are granted.
- Changing a link does not reach copies people already downloaded or exported. Restricting a link is not a recall mechanism.
If your goal is to stop future sharing rather than to audit current access, say so explicitly in your own notes, because the two goals lead to different checks.
Prototype-only sharing and the Starter limitation
Some teams want reviewers to see a flow without opening the design file. That separation is plan-dependent.
Prototype-only sharing is available on paid plans; on Starter, sharing presentation view does not prevent access to the design file. Source
So on Starter, sending a presentation view is not a way to keep the underlying design out of reach. If the design itself is sensitive, the link audience and inherited access are the controls that matter, and they should be reviewed together.
Failure paths to expect
- “I set it to invited only, but a teammate still has access.” Check team and folder membership before changing anything else.
- “The option I need isn’t in Share.” It may depend on plan or workspace policy; confirm with your admin instead of guessing.
- “Someone forwarded the link before I restricted it.” A link change affects the link going forward; it does not retract what was already shared or downloaded.
- “I removed one person and assumed the file was locked down.” Removing a person and restricting a link are separate actions with separate effects.
Where this task ends and another begins
This guide covers access to a Figma file inside a workspace. Removing a published Community file or your creator attribution is a different task with different controls — see the related account-control guide if that is what you need.
Separately, a username search does not control Figma sharing settings, cannot recover an account, and cannot prove who owns a profile. If your concern is what your name and handles expose elsewhere, the next useful step is to review your public account footprint.