Public Link vs Password-Protected Link – Balancing Collaboration Speed Against Unintentional Public Access

Short answer

No. Adobe XD's prototype sharing does not include a built-in expiration setting for either mode. A public link and a password-protected link both stay live until you manually disable or delete them from the sharing dialog. When you revoke a link, the URL stops resolving for new viewers and returns an access error instead of the prototype. Sharing options are not guaranteed to be consistent between the desktop app and the web portal, so verify the controls in the dialog you actually publish from.

Confirmed behavior versus what needs verification

• Documented in XD's final-era releases: two sharing modes (anyone-with-the-link and password-protected), no expiration field, and manual disable or delete as the only revocation control.
• Expected but worth verifying in your installed build: the exact viewer-facing result after revocation (an access error or an unavailable page), and how long cached pages or already-open sessions may continue to serve content.
• Version caveat: Adobe discontinued XD in 2023, so the behavior described here reflects the last desktop builds and will not change through updates. Treat everything below as a baseline to confirm in your own sharing dialog rather than a live product guarantee.

What revocation does and does not undo

Revoking invalidates the URL going forward. It does not reach content viewers already downloaded, exported, screenshotted, or kept open in a session, and client-side caching can let a stale page render briefly afterward. Do not treat the moment you delete the link as an instant global kill switch. Password protection has a parallel gap: it is a shared-secret barrier, not identity-based access. Anyone holding both the URL and the password can forward them together, so for sensitive material a password-protected XD link is best treated as public-with-friction.

Desktop and web dialogs

The desktop Share tab and the web-based sharing view can expose different options and can reflect different published states; the web view may show the last web-published version while the desktop app manages links created from the local document. Because XD is no longer updated, any difference you observe is permanent for your build. Manage each link from the surface where it was created, and check both surfaces before assuming parity.

Verification steps for your own build

1. Publish a throwaway prototype twice: once as a public link, once as a password-protected link.
2. Open each sharing dialog and look specifically for an expiration, auto-disable, or scheduled-access option. If the field is absent, manual revocation is your only control.
3. Revoke one test link, then open its URL in a private or incognito browser window. Confirm you see an access error rather than the prototype, and note whether a session with cached history behaves differently.
4. Repeat the check from the other surface, desktop app versus web portal, and record any differences in available modes, password fields, or link-management buttons.

Practical mitigation while XD remains your sharing tool

• Default to password-protected links for anything not intended for broad distribution, while accepting that the password can be forwarded.
• Keep a simple register of every published link — document, mode, URL, date — and revoke on a fixed cadence, such as the end of each review cycle, rather than relying on memory.
• For requirements XD cannot meet — true expiration, identity-based access, audit trails, bulk revocation — plan to move sharing to a tool that provides them. XD offers no documented API or admin console for bulk link management or revocation tracking.