How to Share a Figma Design Without Sharing the Source File

You want your client to review the new homepage, not wander through every unfinished frame in your working file. That is a reasonable boundary. A design file may contain experiments, internal notes, reusable components, rejected directions and work that has not reached the review stage. Sharing a finished presentation does not always require sharing that entire workspace.

The practical answer is to export the specific design you want reviewed, create a separate preview link and send that link with a clear request. This guide explains how to share a Figma design without sharing the editable source file, when a native prototype is more appropriate, and what a public preview can and cannot protect.

Choose what the client actually needs to see

Start with the decision, rather than the tool. If the client is choosing a homepage direction, they need the composition, hierarchy, copy and visual treatment. If they are testing a checkout journey, they need connected screens and working transitions. If a developer is implementing the approved interface, they may need components, measurements and source access.

These are different deliverables. A static preview is useful for the first situation. A prototype is usually better for the second. A structured source handoff may be necessary for the third. Trying to make one link serve all three purposes creates unnecessary confusion about what is final and what people are allowed to change.

For a small service-business website, you might share the desktop homepage for visual review on Monday, a separate mobile design on Wednesday and implementation access after approval. That sequence keeps the client's task focused without pretending the static mockup is a fully functioning website.

Understand the difference between file access and presentation access

Figma's sharing controls vary by the type of link and plan. Its documentation explains that prototype-only sharing is available on paid plans, while a presentation link on the Starter plan can allow people to open the underlying file in the editor. Check the current Figma sharing documentation before relying on a link as a source-access boundary.

Do not assume that a link looks private because it opens in presentation mode. Test it in a browser where you are signed out. Look at what the recipient can open, navigate to and download. A quick recipient-side check is more reliable than judging permissions from your own account, which already has access to the file.

An exported preview avoids sharing the editable Figma workspace because it is a separate artifact. It does not, however, make the visual design impossible to copy. Anyone who can see a design can potentially capture its appearance. Keep that distinction clear when setting expectations with a client or collaborator.

Prepare a clean frame for export

Duplicate the final review frame into a clearly named presentation area before exporting. Remove internal annotations, unresolved alternatives, stray elements and content that belongs to another client. Check the bottom of long pages, where hidden draft sections or outdated footer details are easy to overlook.

Give the design a useful name, such as “Northline Homepage, Desktop, Review 02.” The name should identify the page and review stage. Avoid a filename that only makes sense to you, such as “final-final-new-7.” The same principle applies to the project title your client will see in the browser.

Read the design at the size at which it will be reviewed. A layout can look convincing at 25% zoom while the actual paragraph text is too small. Confirm that the exported content includes the full page, preserves the intended background and does not cut off shadows, sticky elements or the last section.

Select an export format for the review

A PNG is a straightforward choice for a static website mockup with crisp typography and interface detail. Its clarity still depends on the source dimensions. Exporting a narrow image and stretching it across a large desktop monitor will soften it. Choose dimensions that match the review context and inspect the exported file before uploading.

A PDF can retain vector text and shapes when those elements remain vectors in the export. Photographs and flattened screenshots inside the PDF remain raster images. Putting a low-resolution screenshot into a PDF does not create new detail. For a very long single-page PDF, test it on a phone as well as a desktop, since rendering demands can be different.

WebP can be useful when file weight matters, but check small text and thin lines after compression. Do not choose the smallest file simply because it transfers quickly. The purpose of the preview is to let the client judge the work. For a broader format breakdown, see PNG, WebP, PDF and HTML for website mockups.

Create a separate review link with Swelik

Open Swelik, enter the project name and select the prepared mockup file. Review the chosen filename before creating the preview. When the upload finishes, open the public link yourself and inspect the entire design, including the footer and any unusually tall sections.

Keep the public link and the private management link separate. Send the public link to the client. Save the management link in your own project records, because it gives access to actions such as replacing or deleting the preview. Treat it like an edit credential, even though there is no conventional designer account involved in that workflow.

Swelik previews are unlisted, not access-controlled client portals. Anyone who possesses the public URL may be able to view the design. Do not upload confidential information that requires stronger access restrictions. Unlisted links are convenient for ordinary design reviews, but they are not a substitute for your client's confidentiality requirements.

Send context with the link

A bare URL leaves the client to guess what they are reviewing. Introduce the page, state what has changed and ask for a specific decision. You could write: “Here is the proposed desktop homepage. Please review the section order, headline and overall visual direction. The booking interaction and mobile layout will follow in the next review.”

That message is short, but it does several jobs. It identifies the version, defines the scope and prevents the recipient from interpreting a static button as a broken feature. It also gives them a useful starting point instead of inviting an unlimited review of every possible detail.

If several stakeholders are involved, ask one person to consolidate the response. Record whether the feedback represents a shared decision or an individual suggestion. You do not need a complicated process, but you do need a clear owner for decisions that affect the next revision.

Replace the mockup without restarting the conversation

After revisions, use the private management link to replace the mockup in the existing project. The public URL stays the same, so the client can return to the link already saved in their email or project discussion. Open that public URL again after replacement to confirm the latest version appears correctly.

Send a short change summary when you update the design. “The hero copy is shorter, the services section is now above the testimonials, and the footer contact details are corrected” is more useful than “Updated.” A stable URL reduces link clutter; a change summary helps people understand what they should review next.

Do not use a stable preview link as your only archive. Keep your source file and exported milestones in your own project storage. Anonymous previews can expire, and a review link is not a permanent asset-management system. Record the relevant expiration information before committing to a long client review window.

When you should share the actual source instead

Source access is appropriate when the recipient has a legitimate need to edit the design, inspect the design system or prepare development. The right solution is then to agree on scope, permissions and handoff timing. An exported preview should not be used to obscure a source delivery that your project agreement already requires.

For interactive usability work, a static image can also create the wrong impression. It cannot demonstrate conditional states, keyboard navigation or real form behavior. Use the tool that matches the question being tested. Swelik fits the presentation of a design artifact; it does not turn a static export into a working application.

Questions designers often ask

Can a client edit the Figma file through an exported preview?

An exported image or PDF preview does not grant access to the original Figma file. Keep the original file's own permissions under control, and avoid including a source link in the accompanying message unless you intend to share it.

Does disabling download prevent copying?

No. A download control affects the normal download workflow, but visible material can still be captured or reproduced. Decide what is appropriate to share before uploading it, rather than treating a hidden button as content protection.

Will an exported desktop mockup become responsive on mobile?

A static desktop image can scale to a phone's width, but its layout does not rearrange into a mobile design. If you want feedback on the mobile experience, prepare a mobile frame or an appropriate responsive HTML preview and label it clearly.

What is the simplest repeatable workflow?

Prepare one clean review frame, export at an appropriate quality, create a preview, test the public URL as a recipient, save the management link privately and send a focused review request. For the complete upload walkthrough, follow how to share website mockups with Swelik.