A browser fragment can hold client-side state, but it is not a general secure storage area for subscription credentials. It can remain visible in the address bar, screenshots and shared links. Keep account secrets in an appropriate private record or the supported player fields rather than inventing a fragment-based bookmark.
Visibility still matters
A fragment is normally not sent as part of an HTTP request, but that does not make it invisible to browser scripts or people looking at the screen. A copied full address can carry it to someone else.
Avoid custom credential bookmarks
A bookmark containing username and password values concentrates access data in a place that may sync across devices. If the player offers a supported secure account flow, use that flow. Do not create ad hoc login links for convenience.
Clean up shared evidence
Before sharing a page address or screenshot, review both the query and fragment. Removing only the query can leave private values after #. Rotate exposed service credentials through verified support where appropriate.
A practical sequence
- Keep secrets out of improvised browser bookmarks.
- Inspect query and fragment before sharing links.
- Use the supported player account fields.
An example
A URL ending #password=demo-only still displays that text in a copied address. It is not a private vault merely because the fragment is handled locally.
Questions about this topic
Is a fragment automatically encrypted?
No. It is part of the visible URL text.
Can browser scripts read fragments?
Yes. Client-side code can access the page fragment.
