--- title: The f. url description: f.shebang.pro/ — how an uploaded file's address is built, and what changed for older accounts. --- # The f. url An uploaded object is served at: ``` f.shebang.pro/ ``` using the same 12-character public id sherpage's `p.` addresses use — see [public ids and urls](/concepts/public-ids-and-urls) for the exact alphabet and why it never changes once assigned. ## The old `@handle/slug` form As with sherpage, an older account may still see a file referred to by its owner's handle and slug. Visiting that form answers a `301` redirect — preserving any sub-path and query string — to the id-based `f.shebang.pro/` address, for one release, rather than serving the file directly. New links should always use the public-id form. ## Slug is a label, not an address An object's `slug` is still visible in the dashboard and in a short link's preview card, but it has no bearing on the served url. Renaming it doesn't move or break anything already linking to the file. ## Access isn't stored on the object itself Unlike a page, a sherserve object doesn't carry its own access policy — its short link does. Changing what a file's `f.` address requires goes through `link_set_access`, not a sherserve-specific tool; see [access](/sherlink/access) for why the policy lives there. ## Next [Unlock flow](/sherserve/unlock-flow).