Sharing & permissions

Publishing mints a random token and serves the guide at a /g/<token> URL. The token is not derived from your guide name, workspace, or any sequential id.

A public viewer gets a read-only projection. They cannot see your library, your other guides, your workspace members, or anything about your account, and they cannot edit, comment, or delete.

• Making a guide private clears the token and the URL 404s on the next request. No grace period, no cached public copy.
• Publishing again mints a completely new token, so the link you revoked stays dead permanently.
• Teammates granted the guide directly keep their access through a revoke, because that is a separate grant.

On top of workspace roles you can grant view, edit, or manage on one specific guide, recording, or folder, optionally with an expiry date that stops it applying on its own.

Grants are additive by design. They can open something up to someone who would not otherwise see it, but can never be used to lock an owner out of their own workspace content.

A published guide or video can be embedded in a help center or intranet page. The embed respects publish state, so unpublishing stops the embed resolving too.

• HTML is a single self-contained file with screenshots embedded as data URIs. No image folder, nothing to host.
• Markdown is plain text, for a repo, Notion, Obsidian, or a docs site.
• PDF opens a print-ready page and triggers your browser print dialog. Browser rendering matches what you see, keeps page breaks from cutting through a step, and leaves paper size and margins under your control. A server-side renderer would take all three away.