21 January 2015: a browser paired with the phone
WhatsApp announced its web client on 21 January 2015. The post described a QR code displayed in Chrome and read within WhatsApp to pair the browser with the phone. At launch, the phone had to remain connected; iOS was not yet supported.
This milestone raises a different question from a QR code on a poster: what action is intended? Here, the aim is to use a messaging service in another environment. The symbol’s shape alone does not explain that action; the surrounding journey matters.
Reading the symbol and establishing access are separate steps
To analyse this case, separate three elements:
- The QR code carries information
- Reading retrieves the encoded data. Their meaning then depends on the intended journey.
- The app interprets that information
- A service’s reader can recognise a request related to its own operation. A general-purpose reader does not thereby become that service.
- The service manages access
- Pairing and its management belong to the messaging system, not the arrangement of the QR code’s modules.
This framework does not reconstruct the internal 2015 protocol. It avoids a practical confusion: successfully decoding an image does not mean completing the intended action. The guide to how a QR code works explains reading the symbol; the app and service handle what follows.
2021: an evolution with its own date
On 14 July 2021, the engineering team presented a limited multi-device beta. It described companion devices able to connect independently of the phone, while retaining QR pairing and control over linked devices.
The journey therefore evolved while the QR code remained. Advice from the 2015 announcement should not become a permanent rule about connections, devices or compatible versions. For present use, start with the service’s official help; this retrospective explains the two milestones without providing a current sign-in procedure.
A fictional library, two separate needs
Imagine a library holding a workshop. Its poster offers the public programme at https://example.org/atelier-photo. The printed QR code should simply lead to that page: no pairing with the team’s messaging account is needed to read the schedule.
In the same place, someone may want to read their own messages on their computer. That second need belongs to their service’s pairing journey. It is not prepared by printing that session’s QR code on the workshop poster.
The example is entirely fictional. For the public programme, create a QR code for your page’s address and choose precise wording with the guide to text beneath a QR code. Qurl can encode the chosen address; it does not create WhatsApp pairing QR codes or manage access to that account.
Three questions before pairing
The WhatsApp Web case suggests three questions when a QR code accompanies a sign-in:
- What action is announced? Reading a document, sharing a link and pairing a device are different commitments. If the screen requests pairing when you expected simple information, pause to understand the difference.
- Which device will receive access? Clear information should let you connect the action to the computer you intend to use. A readable code does not answer that question.
- How can that access be managed afterwards? WhatsApp’s help recommends checking linked devices. Find the steps through the service and remove access you do not recognise.
The QR safety guide adds to these pointers. For a simple image containing a public link, the guide to reading on a computer addresses a different need; it does not replace a pairing app. The News article about QR codes and messaging security covers misleading uses more broadly.