A Signal contact link need not contain a readable username

Three shared forms, one contact key

People often talk about a username as if it were a single piece of text, but Signal accepts it in more than one shared form. The exact username can be passed along as text, a QR code can be scanned, and a unique URL can be sent that does not include the username text at all. These are alternate ways of handing over the same kind of contact key. Practically, that means the thing you receive tells you which form you have, and nothing more. An opaque link is not a broken or hidden username; it is simply a link. Do not try to reverse it into text by guessing. [Signal Support: username links, message requests and changes]

• Note which form you received: username text, QR image, or opaque link.
• Use the form as given rather than trying to convert it into another form from memory.

An opaque URL is not a readable identity

A unique Signal URL that lacks the username text can still start the intended chat, yet it gives a reader no name to read off. This is the core distinction: the absence of readable text in a link is not a sign that the link is invalid, and the presence of a name is not proof of who is behind it. Both are sharing formats. Keep your observation narrow: you have a link, and a link is a pointer to a conversation request, not a public profile. [Signal Support: username links, message requests and changes]

After a username change, request a fresh link

A username change has a specific consequence for old contact attempts. After a username change, old username links cannot initiate a new chat with that account, and changes to the username, QR code or link do not notify people in existing chats. So an old link may simply stop working, without any notice to the sender. The right response is not to hunt for a replacement in some searchable list, since none exists. Ask the person to share a current, voluntary link through a channel you already use. [Signal Support: username links, message requests and changes]

• If an old link fails, ask for a current username, QR code or link directly.
• Do not search public directories for a replacement contact key.
• Record the outcome as unavailable if no current link can be shared.

Observation, limit and decision kept separate

It helps to say plainly what you saw and what you cannot conclude. These are different layers, and mixing them leads to overconfident judgments about a contact request.

Why no nonpublic directory shortcut exists

If a username change leaves you without a working contact key, the temptation is to look for a lookup page or a list that maps names to accounts. Signal's sharing model does not provide that. A username exists to be given and received, not to be browsed. That is why the failure path here is to record the contact as unavailable and stop at that access boundary, then ask for a voluntary current link or consult the official current help. Staying at that boundary is not a failure of effort; it is the correct end of what a shared contact key can do. [Signal Support: username links, message requests and changes]

Requests you did not want

The same distinctions apply when an unexpected contact arrives. A username, QR code or opaque link is a way to send a message request, and a profile label may appear once you accept. Signal's sharing forms do not by themselves establish identity, intent or safety. Your decision can therefore be simple and separate from reading tea leaves: decline or ignore, and if you want a specific person to reach you, ask them for a current link through a channel you already trust. Avoid acting on the assumption that a name in a request confirms who wrote it. [Signal Support: username links, message requests and changes]

A couple more questions