Figma version history restore: retention limits and named-version persistence on the Starter plan

Short answer

On Figma’s Starter (free) plan, named versions are just labels on the same version‑history timeline; they are not exempt from the ~30‑day retention window and will disappear together with older entries. Restoring a version and saving a named version both require edit access on the file; view‑only collaborators can browse history but cannot perform those actions. Restoring a file version changes only that file’s canvas state and does not republish, unpublish, or revert components that have already been published to a team library.

Confirmed behavior

• Restoring a version is non‑destructive: Figma copies the chosen historical state to the top of the history as a new current version, so the rollback itself can be undone.
• The free/paid distinction is a plan‑level policy applied to the team that owns the file, not a per‑file setting and not tied to the editor’s personal plan.
• Named versions are annotations on history entries; there is no documented exemption that pins them beyond the Starter retention window.

Likely, but verify

The exact retention length for Starter files is commonly cited as ~30 days, but Figma may adjust plan limits; check the current Help Center for the precise window and any stated named‑version exemption.

Permissions: who can restore

Both the “Restore this version” and “Save to version history” buttons are disabled for view‑only collaborators. No team‑level viewer permission overrides this file‑level edit requirement.

Library publishing independence

Restoring a file version alters only that file’s canvas. Published library components remain at their last published state until a new publish is triggered; the restore does not automatically republish or unpublish anything.

Recommended verification steps

1. Open Figma’s Help Center article “Version history” and note the current Starter retention window and any mention of named‑version exceptions.
2. In a Starter‑team file, save a named version today, then check whether any named versions older than the stated window still appear in the history.
3. With a view‑only test account, open version history and confirm that the restore and save actions are unavailable; repeat with an edit‑access account to see they become active.
4. In a sandbox file that has a published library component, restore an earlier version and verify in the library’s “Updates” panel that the published component stays unchanged until you manually publish again.