How to export your data from Figma

What you can export from Figma, and what stays behind

If a renewal, a seat price change or a residency requirement is forcing your hand, start by knowing exactly what Figma's documented export gives you. The supported route is a local copy of each file in a .fig, .jam or .deck format, and those copies carry no version history and no comments. Figma describes these formats as proprietary and subject to change, so treat a local copy as a way to keep the design file itself, not as a portable record of the work. The gap between a file copy and your team's actual data is where exit plans usually fail. Comments, version history, team and project structure, component libraries that teams publish, plugin configuration, and the people and permissions around each file all sit outside the file. Before you commit to a move, build an inventory with your design leads: list the active team projects, the shared libraries, the files with long comment threads, and the files that other tools link to. Ask Figma's account team to confirm in writing what your plan and admin role allow you to export in bulk, since copying can depend on the file owner's restrictions. A complete exit therefore needs more than file copies. Plan for a separate export of comment threads and version context where your audit or design review process depends on them, a mapping of who owns each file in the new system, and a test import of a representative file set into your target before the old workspace is closed. Your target tool's import path decides what survives the trip, so confirm that behavior against your own files rather than assuming a clean conversion.

Which Figma data has a documented export path

This table lists the main data types a Figma team holds and whether each has a documented local copy path. Read each row to see what the local copy keeps and what it drops, then confirm ownership and permissions in your own workspace before you start. The main takeaway is that a local copy keeps the design file itself but not its history or comments.

Data type	Documented export path	What is not included	What to confirm
Design files (editable design content)	Local copy saved as a .fig file	Version history and comments	Confirm file count and which team owns each file
FigJam boards	Local copy saved as a .jam file	Version history and comments	Confirm which boards are still active and needed
Slides or presentation decks	Local copy saved as a .deck file	Version history and comments	Confirm which decks are still in use
Version history of any file	No documented local copy path	All earlier versions of the file	Record the history you need before you start the move
Comments on files	No documented local copy path	All comments and their threads	Export or record comments through your own process
Files owned by other people or restricted from copying	Depends on owner and permission settings	Any file where copying is blocked for your role	Confirm current owner and permission settings in your own workspace with an admin

What does not come out in a local copy

A local .fig, .jam or .deck copy keeps the design content but leaves behind much of the collaboration record and team structure around it. Each gap below needs a decision before you start a migration, because the file alone will not restore it. The workarounds rely on steps you can carry out with Figma's own interface and on your own records.

Version history

A local copy is saved without version history, so every earlier state of a file is lost once you export only the current version. Anyone who needs to show how a component changed over a release cycle, or who must answer a question about a past screen, cannot recover that from the file. Before the cutoff, export a dated copy of each file you must keep and store it with your release records. Ask your design leads which files need a history trail and confirm that the dated copies are stored in a location with its own retention rules.

Comments and review threads

Comments are not saved in a local copy, so design feedback, approval notes and open questions disappear with the cloud file. Reviewers often record decisions only in those threads, which makes this loss a compliance and audit issue as well as a usability one. Before exporting, review open threads, resolve or summarize them in a document you control, and attach screenshots of the key decisions to the dated copy. Keep the summary with the file so reviewers can trace why a design changed.

Shared library membership

A .fig file carries the components and styles it uses, but it does not record which team library it was linked to or which other files depend on it. After import, a design system can appear as a set of unlinked copies that drift apart over time. Before the cutoff, list each library, its publishing team and the files that subscribe to it. Plan the rebuilt library in your target tool and decide which component set becomes the single source for each product.

Team and project permissions

Who could view, edit or publish a file is set in Figma's team and project structure, and a local copy keeps none of those roles. The file owner becomes whoever opens it, so access rules must be rebuilt from scratch in the new environment. Export the current member list and role assignments for each team and project as a record, then map each role to a group in your identity provider before anyone is invited. Confirm that the role names and permission levels in the new tool match your intended access model.

Prototype links and sharing settings

Prototype flows, share links and embed settings are tied to the cloud file and do not survive a local export in a usable form. Links that teams have sent to stakeholders or placed in tickets will stop working once the original is retired. Inventory the links that appear in your tickets, wikis and product documents, and record which ones must be redirected. Test a sample prototype in the destination tool before you commit, because the Figma exporter plugin does not support prototyping settings.

Why the proprietary format limits what you can do with the copy

The most important point about a local Figma copy is that Figma itself describes the .fig, .jam and .deck formats as proprietary and subject to change. That means a saved file is a snapshot you can hold, but its long-term usefulness depends on whether a tool you can run later still reads it. Treat the local copy as a backup of the design, not as a portable working format, and check it against the tools you expect to need before you rely on it. Figma's help center describes these local copies as lacking version history and comments, so anything your team stored in those layers needs its own export or record.

For archives, the practical step is a test restore. Pick a representative file with components, a shared library, several pages and some text styles. Open the local copy in the destination you intend to use, such as a newer Figma account, Penpot on your own server, or a second machine with no Figma login, and confirm that frames, components, variants, styles and text render as they did in the original. Record which layers, comments, prototype links or plugin data did not survive. For audits, keep the export log, the date, the file owner and the list of known losses together, so an assessor can see what was preserved and what was not.

For future migration, the format question shapes the plan more than any single export button. If a design system or regulated product documentation must stay accessible for years, store a second copy in an open representation the team can verify, such as exported SVG or PNG for key screens, plus a written inventory of tokens and components. Confirm with your procurement or legal team how long the organization must retain design records, and ask any migration partner to test a sample of files in the target tool before committing to a full move. The Figma help center article on saving local copies is the place to confirm the current file types and behavior.

How to run a complete export from Figma step by step

This sequence moves every Figma file your organization owns into copies stored on your own infrastructure, with comments and version notes recorded separately and a check that nothing was missed.

Inventory every file and its owner
Before anyone downloads anything, list every Figma file, its project, its team and the person who owns it. Record the page count for each file alongside the list, since you will compare against these numbers later. Ask each owner to confirm which files are still active and which are obsolete, so you do not copy stale work by accident. The step is done when you have a single spreadsheet with one row per file, listing file name, team, owner, page count and status.
Save a local copy of each file
Open each file in Figma and use the local save option to create a .fig, .jam or .deck copy on a device you control. Figma's help center describes these as local copies without version history or comments, so treat them as a snapshot of the current design only. Name each copy with the team, project and date so it can be matched back to your inventory. The step is done when every active file in the inventory has a local copy with a matching name.
Record comments and version notes separately
Local copies do not carry comments or version history, so capture those by hand or with an approved method. For each file, export or note open comments, resolved threads that matter for audit or design decisions, and any version names the team relies on. Store these notes as text or PDF next to the matching design copy. The step is done when each file folder holds a companion document that lists comments and version history for that file.
Confirm owner restrictions on copying
Check each file's sharing and permission settings before copying it out, and confirm with the owner or the workspace administrator that copying is allowed under your contracts and internal policies. Some files may be restricted, owned by a departed employee or shared from another organization. Keep a short log of who approved each copy. The step is done when every file in the inventory is marked as cleared, held or excluded, with the approver recorded.
Store copies in your own infrastructure
Move the approved copies, companion notes and inventory into storage you run, such as a file server, an object store or a backup target under your own control. Apply your existing access controls, encryption and retention rules to that location. Keep the folder structure matching the inventory so the mapping stays clear. The step is done when the storage location holds every cleared copy and its notes, and the storage team confirms the access rules are in place.
Verify file and page counts against the inventory
Count the files in your storage location and compare that number with the cleared rows in the inventory. Then open each copied file and compare its page count with the number recorded in step one. Any mismatch should be investigated before the file is marked complete. Record totals and exceptions in the inventory. The step is done when file and page counts match for every cleared file, or each difference has a documented reason and an owner.
Open and compare a sample of copies
Pick a sample of files that spans teams, file sizes and complexity, and open each copy in an application that can read the format your organization needs. Compare layers, components, frames and text against the live file in Figma. Look for missing fonts, broken images and lost component links. Note every difference in the log. The step is done when each sampled file has a recorded comparison result and any gaps are assigned to a named person for follow-up.
Document the format and the limits
Write a short record that states the formats used, the date of the export, the people who approved and verified it, and the known limits, including the proprietary and changing nature of the .fig, .jam and .deck formats that Figma describes. Keep this record with the export so a future reader knows what the archive can and cannot restore. The step is done when the record is stored with the export and has been reviewed by the file owners.

Using Figma's official APIs for tooling and bulk work

Design operations leads usually need an inventory before any file moves: which files exist, which projects hold them, who owns each one, and which shared libraries other teams depend on. A script that reads file and project metadata can produce that list in a spreadsheet. This is often the first useful output of an export project, and it works even when the design files stay in Figma for now.

File inventory: Record file name, project, owner, team and last modified date so every file has a named owner before any migration starts.
Library dependencies: Note which files publish or consume shared libraries, because those links decide the order of any move.
Retention decisions: Mark each file as archive, migrate or retire. Retired files should carry a recorded sign-off with the owner's name and date.
Handoff format: Export the inventory as CSV so procurement, compliance and project leads can review it without needing Figma seats.

Confirm in Figma's developer documentation which read operations are available for listing teams, projects and files, and whether your plan and seat types allow the calls you intend to make.

Where the exported files go next with self-hosted Penpot

The next step for a team moving to Penpot is to run the Figma exporter plugin, which converts Figma files into a .zip that Penpot can import. The plugin is maintained by Kaleidos under the Mozilla Public License 2.0, the same license as Penpot itself, so the conversion tool can be reviewed and adjusted by your own engineers. Treat the plugin output as a working copy, not a finished handoff. The plugin does not support prototyping settings, so any flows, transitions or interactive states built in Figma will need to be rebuilt by hand in Penpot or documented for the designers who own them.

Before anyone signs off a migrated file, run a fidelity check against the original. Open the imported file in your self-hosted instance, compare each page and frame with the Figma source, and check text rendering, fonts, spacing, layer order and image crops, since these are the areas where conversions most often drift. Keep the original .fig, .jam or .deck copy and the exporter's output together so a reviewer can trace any difference back to its source. Confirm with the plugin's repository which Figma features it handles in the version you plan to use, because support can change between releases.

For how components, variants, auto layout, libraries and text convert, and how to handle large files, read the migration sibling page, Migrate from Figma to Penpot. Plan the fidelity review as a set of named files with named reviewers, and agree in writing who signs off on each one before the Figma license is reduced or ended.

What to plan before the Figma contract ends

Export work is easier when the decisions come first. The cards below cover the items to settle before a renewal or termination date, from the export deadline to where copies live and whether data residency changes the picture. Confirm the exact notice and retention terms in your Figma contract before you set any internal dates.

Set the export deadline

Work backward from the date your Figma access ends, not from the date you plan to start copying. Ask your Figma account team or check your contract for the notice period and any data retention window after termination. Build the export schedule around the largest team's files, since those take longest to save locally. Treat the contract end date, not the export date, as the hard deadline.

Assign an inventory owner

Someone must own the list of every team, project, draft and shared library that lives in Figma, including files that few people open. Without a named owner, orphaned files and personal drafts are the ones most likely to be lost. The inventory should record file owner, team, last edited date and whether the file is a shared library that other files depend on.

Choose where copies are stored

Local .fig, .jam and .deck copies are saved to a machine or storage location you choose. Decide before export which approved server or storage volume will hold them, and who can read it. Local copies on laptops are hard to audit and easy to lose, so plan a central location with access controls and backups.

Decide who can read the copies

Local copies contain full design content, including unreleased product screens, copy and component libraries. Confirm which roles need access after the switch, and whether design files from regulated product lines or client work need tighter restrictions. Record the access list so the migration does not quietly widen who can see sensitive designs.

Archive comments separately

Local .fig, .jam and .deck copies do not include comments or version history. If design feedback matters for audit trails, client approvals or design decisions, plan a separate archive. Options include exporting comment threads as screenshots or notes into a document system, and deciding what counts as a record worth keeping before the account closes.

Check whether residency settings matter

If your organization uses Figma's EU or other localized hosting, find out whether that setting applies to the files you are exporting and where they are held today. Figma's data residency solution is available only on the Enterprise plan, and comments, file names, plugins, fonts and preview thumbnails are not hosted in the chosen region. Confirm with Figma what that means for your records before deciding where the export goes.

Questions buyers ask before exporting from Figma

How much effort does a full Figma export take?

The effort depends mainly on how many files and libraries you hold, how many of them depend on each other, and how much review history sits in comments. Figma's local copies are saved as .fig, .jam or .deck files, and they carry no version history or comments, so any comment threads you need to keep must be recorded separately before you start. Teams with a few projects and a single shared library usually face a small inventory task. Teams with hundreds of files, nested libraries and years of comments face a larger one, because each file needs a check for links and missing fonts. Ask any partner to inventory the workspace first and to price the work from that written inventory.

Can our team export Figma files without outside help?

Yes, a team with admin access and a clear file inventory can save local copies on its own. Figma's help center describes saving local copies of files, and that step does not need a vendor. What an internal team often misses is everything around the copy: version history, comments, plugin data, shared library links and access rules are not carried over with a .fig file. Outside help is most useful when you need those pieces mapped to a target platform, verified after import and documented for your records. Decide early which of these you will handle internally and which you will scope externally.

What do Figma admins and designers need to do?

Admins need to confirm which workspace and team files exist, who owns each file, and whether the organization's policies allow copying designs out. Figma's owners can restrict copying, so an admin may need to change sharing settings or ask a file owner for permission before a designer saves a local copy. Designers should list the files they own, note which components and libraries their work depends on, and record any open comment threads that matter for approvals. Both groups should agree on a single location for the exported files and a named person who signs off on each batch.

Are local Figma copies enough for an audit?

Local copies may not be enough on their own. A .fig, .jam or .deck file holds the design content but not version history or comments, so it cannot show who approved a change or when. Figma describes these formats as proprietary and subject to change, which also limits how long an exported file can be read by other tools. Before an audit, ask your compliance lead which records the auditor expects for design approvals and whether the exports need an accompanying log. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors decide what is sufficient.

Which file formats should we expect after leaving Figma?

Expect the proprietary Figma formats first, then a conversion step for any target platform. Penpot, licensed under the Mozilla Public License 2.0, works with open standards such as SVG, CSS, HTML and JSON, and its Figma exporter plugin converts Figma files into a .zip that Penpot can import. That plugin does not support prototyping settings, so those must be rebuilt by hand. Check component variants, auto layout and text rendering after import, because fidelity varies by file. Ask your target platform which conversions it supports before you commit to a timeline.

What does a DeployOpen scope cover for a Figma export?

A DeployOpen engagement is fixed-scope, so the written scope defines the work, the deliverables and the timeline before anything starts. Typical items, depending on what you agree, include an inventory of files and libraries, an export plan, handling of the export into your own infrastructure, a fidelity check after import and documentation for your records. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Cost depends on the written scope, so ask for a quote built from your inventory rather than a general estimate.

What drives the cost of an export up or down?

Cost follows the amount of work the scope contains. The main drivers are file count, library dependencies, the volume of comments you need to keep, the number of prototypes that must be rebuilt, and how many people must review the results. One-time work includes the inventory, the export and the verification. Recurring costs come from keeping the target platform running, which for self-hosted Penpot includes PostgreSQL, Valkey and object storage. Ask any quote to separate one-time migration work from ongoing operations so you can compare it with your current subscription.

Keeping records that the file copy does not hold

A local copy of a Figma file does not carry its comment threads, version history or sharing settings. Figma's help documentation states that the .fig, .jam and .deck files it saves locally exclude version history and comments, so anything your team needs from those areas has to be captured separately before you leave the platform. Treat the file copy as the design itself and treat the surrounding record as a second deliverable with its own owner. Without that record, a later question such as why a component changed or who approved a color decision has no answer in the exported file. Start with an inventory per project. List the open and resolved comment threads you need to keep, the named versions that marked design decisions or handoffs, and the members and their roles on each team and file. Confirm with Figma which of these can be exported in bulk, which need to be copied by hand or through the official APIs, and whether the output includes timestamps and author names. Record the date of each capture and the file version it refers to, so a dated export can be matched against the design file it describes.

Store these records in a system that your audit trail already covers, with restricted write access and a retention period set by your records policy. Access lists matter as much as design content, because they show who could see or change a file at a given time, and that information is not part of the file copy. Ask your compliance lead which evidence they expect for design approvals and how long it must be kept. If you later move to Penpot, these archived records remain your reference for decisions made in Figma, since the migration itself will not bring the comment history across.

How DeployOpen scopes and delivers a Figma exit

DeployOpen plans, implements and hands over self-hosted open-source platforms inside the client's own infrastructure, so an export from Figma becomes a controlled migration rather than an ad hoc download. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory which Figma files, libraries, comments and version history must leave, and which can be archived instead.
Confirm which Figma plan and admin rights the client holds, since copying restrictions depend on file ownership and permissions.
Agree in writing the target Penpot environment, data location, login method and the export formats each team needs.

How we build

Deploy a self-hosted Penpot instance in the client's own cloud account, data center or closed network using Docker Compose or Helm.
Run a test export with the Penpot Figma exporter plugin on representative files and record what converts and what does not.
Configure PostgreSQL, Valkey, object storage and the chosen single sign-on or LDAP login, then test them before any team is moved.

How we hand over

Provide written documentation of the export procedure, the import checks and the known conversion gaps, such as prototyping settings.
Deliver a fidelity checklist that design leads can use to sign off each migrated file or library before the Figma copy is retired.
Keep local .fig, .jam and .deck archives in a documented location so the original design history remains available.

How we support

Offer ongoing support, upgrades and testing as a retainer after the fixed-scope delivery is complete.
Plan Penpot version upgrades and backups in the client's environment, with documented steps for each release.
Ask any provider to confirm which items sit outside the client's control, such as third-party plugins or vendor-hosted services, before scoping begins.