01You join a line
The moment you press the button, your browser tells a server, "I am here and I want a match." The server puts you in a waiting pool, a queue, along with a few facts about your request: text or voice, any country preferences you set, and when you arrived.
If someone compatible is already waiting, you are paired almost instantly. If not, you wait for the next person to arrive. That is the whole reason wait times vary: a random-chat service can only ever match the people who are online at that exact moment. At 3am in one time zone the pool is busy; at 3am in another it is thin.
02Filters are a trade, not a feature
Every filter shrinks the pool you can be matched from. Ask for one country and you can only be paired with people from that country who are waiting right now. Ask for a country that is asleep, and you may wait a long time.
The narrower your request, the smaller the crowd it can be answered from.
Most services handle this with a fallback. On TalkLive, if your country settings have not produced a match after about ten seconds, they are set aside and you are matched with whoever is available, rather than waiting indefinitely. Blocking a specific person is different: someone you have blocked stays blocked.
03The handshake
Once two people are paired, the server's main job is nearly over. It introduces the two browsers to each other and passes a few short messages back and forth, a process called signalling. Each browser describes what it can do (which audio formats, for instance) and how it might be reached on the network. This is done with a standard built into every modern browser called WebRTC, short for Web Real-Time Communication.
04The thirty-year-old problem
Ideally the two browsers would then talk directly. Usually they cannot, at least not easily. Most home and mobile connections sit behind a router doing network address translation, which lets many devices share one public address and, as a side effect, makes it hard for anyone outside to reach a specific device inside.
WebRTC tries several tricks to get around this. A small helper called a STUN server tells each browser what its public address looks like from the outside, and the browsers try connecting to each other's addresses at the same time, hoping to punch a hole through. Often it works. On some mobile networks and strict office or university networks, it does not.
For those cases there is a TURN server: a relay in the middle that both sides can reach. The audio goes to the relay and straight back out to the other person. It costs the service bandwidth, which is why some apps skimp on it, but without it a noticeable share of calls would silently fail to connect.
05What is encrypted, and what isn't
WebRTC audio is encrypted by design; browsers do not allow an unencrypted call. Even when audio passes through a relay, the relay forwards encrypted packets. The service still sees things around the call: that two connections were matched, when, and roughly where from, because that is how matching and abuse reports work.
Encryption also says nothing about the other person. Whoever is on the other end hears everything you say and can record it with their own device. No protocol can prevent that.
06Why "random" is never quite random
Pure randomness would be a bad experience. A good matcher quietly avoids pairing you with the person you just skipped, with someone you blocked, or with someone you were matched with seconds ago. It may consider language or region. Each rule makes the result less random and, in theory, better.
Which raises a question with no clean answer: how many rules can you add before random chat stops being about chance at all, and starts being about an algorithm deciding who you should meet?