How WhatsApp Works: Messaging Architecture, End-to-End Encryption & Message Delivery

1. What is WhatsApp?

Priya is in Mumbai. Her friend Sam is in London, and she types "Hey, are you coming?" and presses Send. A second later a grey tick appears, then a second tick, and when Sam looks at his phone both turn blue. This article follows that one message all the way: what her phone does with it, what crosses the internet, what WhatsApp's servers can and cannot see, where the message waits when Sam's phone is off, and what each tick actually proves.

WhatsApp is an internet messaging service used, by its own count, by more than 3 billion people in over 180 countries . It began as an alternative to SMS , and it still looks like one: you sign up with a mobile phone number , verified by a code sent by SMS or a phone call . But nothing after that uses the phone network's messaging system. Messages, photos, documents, location and calls all travel as data , over whatever internet connection the phone has. WhatsApp supplies none of that connection: you bring your own device and data plan , which is why the service is free but "data charges may apply" .

Four ideas this article keeps coming back to

• Internet messaging. Your phone talks to WhatsApp's servers over an ordinary internet connection, and the servers pass messages on. There is no direct phone-to-phone link.
• Message routing. A message is addressed to a person but delivered to devices: a phone, and up to four linked computers, tablets or phones . Getting a message to the right devices, even ones that are switched off, is most of what the servers do.
• End-to-end encryption. WhatsApp defines this as encryption from a device the sender controls to a device the recipient controls, with no third party, WhatsApp and Meta included, able to read the content in between . The servers route ciphertext.
• Acknowledgement. The ticks are reports that come back from different places: one from WhatsApp's servers, one from the recipient's device, one from the recipient opening the chat. Each proves something different (chapters 9 to 11).

How this differs from SMS

An SMS travels through the mobile operator. The SMS standard is built around a Service Centre that stores and forwards each short message , so every text passes through operator infrastructure rather than going phone to phone . The Service Centre keeps the message until it is delivered or its validity period runs out , and the SMS transfer layer defines no end-to-end encryption between handsets, so the operator necessarily holds the content while delivery is pending . A single SMS carries at most 140 bytes , 160 characters in the basic alphabet ; longer texts are split into several messages and joined back together .

A typical internet service fixes the size limit and the operator problem but not the trust problem. Its app encrypts the connection to its servers with TLS, which keeps the network out, but TLS ends at the server, so the service itself can read what you send . End-to-end encryption adds a second layer inside the first, so that even the service in the middle handles only ciphertext. On WhatsApp, the message is encrypted twice in transit: end-to-end inside, and a separate client-to-server layer outside, which the server removes to find routing information and an end-to-end ciphertext it cannot open .

What this article can and cannot tell you

WhatsApp publishes a detailed encryption whitepaper, first released in April 2016 and at version 9 as of February 2026 , plus engineering posts, privacy policies and developer documentation. Those describe the cryptography and the product's behaviour in detail. They do not describe WhatsApp's server software, databases, data centres or internal message formats, so this article never names them. Every diagram and simulation is marked as documented, conceptual (a simplified picture of documented behaviour) or illustrative (a standard technique WhatsApp may or may not use), and every claim links to its source in the list at the end.

The whitepaper describes WhatsApp's own client software. Messages to businesses that use Meta's or another company's hosting are a documented exception to end-to-end encryption (chapter 20).

2. The complete architecture

Strip WhatsApp down to what it is documented to do and there are only two kinds of participant: devices, which hold keys, encrypt, decrypt and display, and WhatsApp's servers, which connect, authenticate, hold and deliver. Almost everything interesting about the design comes from keeping those roles apart.

The devices

Each device has its own long-term identity key pair, generated when the app is installed , and its own set of encryption keys, so compromising one device's keys does not decrypt messages sent to the user's other devices . An account has exactly one primary device, the phone the account was registered on, which links the others . Meta's description is blunt: the private key stays on the device, and nobody, WhatsApp included, has access to it .

The servers' documented jobs

The whitepaper and Meta's posts describe what the server side does without describing how it is built:

• Connection and authentication. Every app keeps a long-running connection to WhatsApp encrypted with Noise Pipes (Curve25519, AES-GCM, SHA256) . Clients authenticate with a Curve25519 key pair, and the server stores only the public half , so a breach of its user database would reveal no private credentials . In 2021 Meta named the front-end service that handles these connections ChatD ; nothing more about it is public.
• A directory of public keys and devices. Devices upload their public keys at registration , and the server stores them against the account , along with each account's list of device identities .
• Holding and delivering messages. While a message is in transit, the servers store it temporarily, encrypted . If the recipient's device is online it is delivered straight away; if not, it is stored for up to 30 days and a push notification is sent . Once delivered, it is deleted .
• Storing encrypted media. Attachments are encrypted on the phone and uploaded to a blob store .

WhatsApp runs on Meta's global infrastructure and data centres, including in the United States . Beyond that sentence, where those servers are and how they are divided is not published.

Reading the diagram

Select any box or line to see what it does and which sources say so. Play the journey to follow one message. The boxes inside "WhatsApp servers" are responsibilities, not services: WhatsApp has not said whether the key directory and the message relay are one system or a hundred, and the diagram does not pretend to know. What the documents do settle is the direction of trust. Devices decide what is encrypted and for whom; servers see envelopes, public keys and ciphertext.

Not documented: WhatsApp's server languages and frameworks, databases, queueing systems, regions and data-centre layout, internal message formats and the transport protocol under Noise. Older talks and third-party articles make claims about some of these; none comes from a current WhatsApp or Meta source, so none is used here.

3. What happens when you press Send?

Here is the everyday path, both phones online, read receipts on, in ten stages. Each one gets its own chapter later; this is the map.

• Compose. Priya types the message. It exists only on her phone, which is where WhatsApp says messages are stored, not typically on its servers .
• Send. She presses Send.
• Encrypt on the phone. Her phone encrypts the message separately for each of Sam's devices, using the session it has with each one: WhatsApp calls this client-fanout . Each message gets its own key, which changes for every message , and the text is encrypted with AES-256 and authenticated with HMAC-SHA256 .
• Cross the internet. The ciphertexts travel inside her phone's encrypted connection to WhatsApp .
• The server holds it. WhatsApp's servers store the message, still encrypted, for delivery .
• One tick. The message counts as sent once it is sent successfully from WhatsApp's servers; WhatsApp shows that as one check mark .
• Delivered to a device. Sam's phone is online, so the server delivers its copy and deletes it .
• Decrypted there. Sam's phone decrypts it with its own session keys. Only now does the text exist anywhere outside Priya's phone.
• Two ticks. The message has been delivered to Sam's device: two check marks .
• Blue ticks. Sam opens the chat. The message was displayed in an open chat thread on his device, which WhatsApp shows as two blue check marks .

Why two separate ticks?

Because the two events happen in different places and can be hours or weeks apart. The first tick is a statement by WhatsApp's servers about themselves: we have it. The second is a statement by Sam's device: I have it. Between the two, the message can wait on a server for up to 30 days . A design that showed a single "sent" indicator would hide exactly the information people use the ticks for.

What the simulation leaves out

The lab assumes Priya's phone already has a session with Sam's phone; setting one up is the next chapter. It tracks where encrypted data is, but shows stand-in bytes rather than real ciphertext; chapter 5 does real encryption in your browser. And it names its events (MESSAGE_SUBMITTED, MESSAGE_ACCEPTED and so on) for this article: WhatsApp's wire protocol is not public.

4. How devices set up a secure session

Before Priya's phone can encrypt anything for Sam's phone, the two need shared secret keys. They have never been in contact, Sam's phone may be switched off, and the only thing between them is a server that must not learn the keys. The solution WhatsApp documents is a set of public keys each device publishes in advance.

What every device publishes

At install time a device generates three kinds of Curve25519 key pair:

• an identity key pair, long-term ;
• a signed pre key, medium-term, signed by the identity key and rotated periodically ;
• a queue of one-time pre keys, used once each and replenished as needed .

At registration it uploads the public halves: identity key, signed pre key with its signature, and a batch of one-time pre keys . The server stores them against the account .

Setting up a session

When Priya's phone first writes to one of Sam's devices, it asks the server for that device's public identity key, signed pre key and a single one-time pre key . The server hands the one-time pre key out once and deletes it . If Sam's batch has run out, the server returns none, and setup goes ahead without it .

Priya's phone then generates a fresh ephemeral key pair and computes four Diffie–Hellman agreements between its keys and Sam's, concatenating them into a master secret :

``text master_secret = ECDH(I_priya, S_sam) ‖ ECDH(E_priya, I_sam) ‖ ECDH(E_priya, S_sam) ‖ ECDH(E_priya, O_sam) I = identity key · S = signed pre key · E = ephemeral key · O = one-time pre key ``

The last term is simply left out if there was no one-time pre key . HKDF, a key derivation function, turns the master secret into the session's root key and chain keys .

Each Diffie–Hellman agreement has the same useful property: two parties combine their own private key with the other's public key and get the same value, while someone who sees only the public keys cannot. The server has every public key in that formula and none of the private ones.

Sending before the other side answers

Priya can send immediately, even if Sam's phone is offline . Until Sam replies, every message she sends carries the information his device needs to build the matching session: her ephemeral and identity public keys . When his phone receives it, it recomputes the same master secret from its private keys and deletes the one-time pre key that was used .

Sessions are long-running. They are only rebuilt when session state is lost, for example after a reinstall or a new device , and Priya's phone keeps a separate session with every one of Sam's devices and with every one of her own other devices .

The whitepaper's description of the receiving side says "the initiator" derives the keys at a point where, from context, it must mean the recipient; this looks like an editorial slip in the document, not a different protocol .

Why the one-time pre key matters

Signal's X3DH specification, which WhatsApp's setup closely follows, explains the four terms: the first two give mutual authentication, the last two forward secrecy . It also warns that an initial message sent without a one-time pre key can be replayed , and that a malicious server's main extra power, given authenticated keys, is to withhold one-time pre keys . That is why devices replenish them. How large WhatsApp's batches are and how often signed pre keys rotate is not published ; the X3DH specification suggests rotating signed pre keys weekly or monthly, where WhatsApp says only "periodic" .

Companion devices are vouched for

A linked device's keys are signed by the account's primary phone at linking time, and the server returns those signatures with the device's keys . If either signature fails to verify, the sender aborts and sends nothing to that device . This is what stops the server from quietly adding a device of its own to someone's account.

5. End-to-end encryption

Plaintext is the readable message: "Hey, are you coming?". Ciphertext is what encryption turns it into: bytes that look random to anyone without the key, a secret value that makes the transformation reversible. Good encryption gives two guarantees. Confidentiality: without the key, the ciphertext reveals nothing useful about the plaintext. Authentication: if anyone alters the ciphertext, the recipient can tell, and refuses it instead of showing garbled or forged text.

End-to-end encryption is a statement about where the keys are. WhatsApp defines it as encryption from a sender-controlled device to a recipient-controlled device, with no third party able to access the content in between, "not even WhatsApp or Meta" , where a third party is any organisation other than the people in the conversation . WhatsApp's privacy page puts it in one line: only the sender and recipient have the key needed to read personal messages, calls, photos and videos .

What WhatsApp actually uses

Each one-to-one message is encrypted with AES-256 in CBC mode and authenticated with HMAC-SHA256, under a key used for that message only . That message key is 80 bytes: a 32-byte AES key, a 32-byte HMAC key and a 16-byte initialisation vector . It changes for every message and cannot be reconstructed from the session's state once the message has been sent or received .

Why the server does not need the plaintext

Delivering a message takes an address, not its meaning. The server needs to know which account and device a ciphertext is for, and how big it is. Everything else it can treat as opaque bytes. WhatsApp says messages are encrypted before they reach its servers, so it cannot see them , and that it cannot see the undelivered messages it holds for the same reason . Encryption has no off switch: all chats use the same Signal protocol , and a chat's end-to-end status cannot change without a visible system message .

Try it

The lab encrypts a message for real, with AES-256-GCM in your browser. GCM is a different mode from WhatsApp's CBC-plus-HMAC, but it does the same two jobs in one step: NIST's specification describes it as providing both confidentiality and authenticity , and the browser's Web Crypto API refuses to decrypt a ciphertext whose authentication tag does not verify . Change a letter and every byte of ciphertext changes. Alter one byte "in transit" and decryption fails. Switch to the delivery service's view to see what a server in the middle has to work with.

This lab is a generic demonstration of authenticated encryption, not WhatsApp's or Signal's code: it shares one key between two panels, where WhatsApp derives a fresh key per message on each phone and never sends it .

Where end-to-end encryption stops

It protects content between devices. It does not protect a message on an unlocked phone, a screenshot, or a forwarded copy; WhatsApp's policy notes that anyone can screenshot a chat or record a call . And it does not cover chats WhatsApp does not class as end-to-end encrypted: communications with Meta's own services and with businesses that use Meta's Cloud API . Chapter 20 covers those.

6. The Signal Protocol and forward secrecy

WhatsApp states that the Signal Protocol, designed by Open Whisper Systems, is the basis of its end-to-end encryption , and that its implementation is based on the open-source libsignal-protocol-java library . The part of the protocol that matters most after a session exists is the ratchet: the way message keys keep changing.

Two ratchets

The symmetric-key ratchet. A session holds a 32-byte chain key . To encrypt a message, the phone derives a message key from it and then moves the chain key forward:

``text Message Key = HMAC-SHA256(Chain Key, 0x01) Chain Key = HMAC-SHA256(Chain Key, 0x02) ``

Both formulas are in WhatsApp's whitepaper , and they use the same constants as Signal's Double Ratchet specification . HMAC is one-way: from a message key you cannot work back to the chain key that produced it, nor to any earlier one .

The Diffie–Hellman ratchet. Every message advertises a fresh ephemeral public key . When a reply arrives, the two sides combine their latest ephemeral keys in a new Diffie–Hellman agreement and feed the result, with the root key, into HKDF to get a new root key and chain key . So a new agreement happens on every round trip .

What this buys

• Forward secrecy. Old message keys are deleted and cannot be recomputed, so someone who obtains a phone's current keys still cannot decrypt messages sent earlier . WhatsApp attributes forward secrecy to the hash ratchet and the DH ratchet together .
• Recovery after a compromise. The symmetric chains on their own give no break-in recovery; that comes from the DH ratchet, which mixes in randomness an attacker who stole one chain key does not have .
• No key reuse. Each chain carries only one person's sending direction .
• Tolerance of the real world. Because of how the keys are derived, messages can arrive late, out of order or not at all without breaking decryption .

One detail does not add up in the whitepaper itself: the message key is defined as 80 bytes, but HMAC-SHA256 produces 32, and version 9 does not describe the expansion step . Signal's specification expands the HMAC output with HKDF into exactly the 80-byte layout WhatsApp describes , so that is the likely reading, but it is not documented by WhatsApp.

WhatsApp versus the current Signal specifications

WhatsApp's documented session setup has the classic X3DH shape: identity key, signed pre key, optional one-time pre key, four Curve25519 agreements into HKDF . Signal has since published PQXDH, which adds post-quantum KEM pre keys to the bundle while still relying on classical assumptions for authentication , and revision 4 of the Double Ratchet specification adds a "Triple Ratchet" with a post-quantum component . WhatsApp's whitepaper version 9 describes neither; whether WhatsApp has deployed any post-quantum key agreement is not stated in it or in any Meta engineering post found for this article .

Signal's specifications index lists X3DH, PQXDH, the Double Ratchet, Sesame and others, but no Sender Keys specification , so WhatsApp's group scheme (chapter 15) has no public Signal document to compare against.

A faster ratchet for live location

Live location sends many small, lossy updates. WhatsApp documents that Signal's linear ratchet is too slow for that, and uses a multi-dimensional chain-key ratchet instead , in which a receiver can skip many iterations at a time while still destroying every chain key on the path to a used message key, which keeps forward secrecy .

7. How messages travel through the internet

Between Priya's phone and WhatsApp's servers lies the ordinary internet: her home Wi-Fi or mobile network, her provider's network, and a chain of routers no one at WhatsApp controls. WhatsApp supplies no connectivity of its own; users provide their own devices and data connections . What it does control is what goes inside the connection.

Packets and routes

The internet moves IP datagrams: blocks of data addressed from one host to another . Routing means choosing, at each step, the path a datagram takes towards its destination address . Each router decrements a counter, the time to live in IPv4 and the hop limit in IPv6, and drops the packet if it reaches zero, so a lost route cannot loop forever . IP treats every datagram independently and promises nothing about reliability, flow control or ordering : no acknowledgements and no retransmission .

A reliable stream on top

Something has to turn lost, duplicated and reordered packets into a dependable conversation. TCP is the classic answer: it gives applications a reliable, in-order byte stream , numbering bytes, detecting losses and retransmitting . It starts each connection with a three-way handshake . One gap matters for messaging: TCP does not itself notice that an idle peer has vanished , so apps need their own ways to detect a dead connection. Which transport WhatsApp runs underneath its encryption is not documented .

The encrypted connection

Inside the connection, WhatsApp uses Noise Pipes, from the Noise Protocol Framework, with Curve25519, AES-GCM and SHA256 . Noise is a framework for building protocols from Diffie–Hellman key agreement : a handshake exchanges public keys and hashes the agreements into a shared secret, and later messages are encrypted with it . Noise Pipes, as the framework defines it, does a full handshake the first time, lets the client cache the server's key, and then uses a faster zero-round-trip handshake on reconnection, falling back if that fails . WhatsApp describes its transport as giving very fast, lightweight connection setup and resumption , and as hiding the connecting user's identity from network observers . The exact handshake patterns it uses are not named .

That connection is the outer layer. Inside it is the end-to-end ciphertext from chapter 5, which the server cannot open when it removes the outer layer .

Why not just TLS?

TLS, the protocol behind https, does the same job for the web: a secure channel between two peers over a reliable stream , always authenticating the server and detecting any tampering . Two of its limits show why WhatsApp needs more than a transport layer. TLS does not hide the length of what it carries ; and its endpoints are the client and the server, so on its own it leaves content readable at the server . The same is true of Noise Pipes. Only the second, end-to-end layer keeps the server out.

If you have read Bit Culled's NATS deep dive, the shape is familiar: a client keeps one long-lived connection to a server and every message rides on it. The difference is what the server can read.

8. Message routing: from an account to its devices

"Send to Sam" is not an address WhatsApp's servers can deliver to. Sam is an account; what receives messages is each of his devices, and each one has its own keys. Routing a WhatsApp message means turning one person into a list of devices, encrypting a copy for each, and getting every copy to the right place.

Lists of devices

The server maps every account to all its device identities, and senders fetch device lists from it . Each list is signed by the account's primary phone , and the primary uploads a new signed list whenever a device is removed, and periodically anyway with a fresh timestamp . Lists expire after at most 35 days; a sender holding an expired list talks only to the primary device .

Client-fanout

With the list in hand, the sender encrypts and transmits the message once per device: one message to N devices is N encryptions and N transmissions . That has a consequence the rest of the design has to deal with: a device that was not on the sender's list at the moment of sending cannot read that message, because no copy was encrypted for it .

Catching a stale list

WhatsApp's answer is Sender Side Backfill. The server compares a hash of the devices the sender encrypted for with a hash of its own device records, and tells the sender to refresh if they differ . The sender then verifies the new devices, builds sessions and resends the original message to them, but only within a short window after sending . Backfill is never sent to devices of a recipient whose identity key changed, for example after re-registering their phone .

Signal's Sesame specification solves the same problem differently: its server accepts a message only if the sender's device list is current . WhatsApp does not cite Sesame, but its hash check plays the same role, with a resend instead of a rejection .

What a routing table is not, here

In a server-readable system, routing can look inside a message: route by content, filter, index, deduplicate on the server. Here the server routes by envelope alone. Every copy is a different ciphertext, encrypted for a different device's keys, and the server's job is to hold each one until its device collects it. How those per-device queues are stored is not documented .

9. The life of a message

From the sender's point of view, a WhatsApp message passes through a small number of states, and only ever forwards. Some are shown in the app; others exist only as facts about where the encrypted data is.

State — Where the message is — What the sender sees; Composed — On the sender's phone, as plaintext — The text in the input box; Waiting to send — On the sender's phone, being sent — A clock (not defined in the sources we could read); Sent — Accepted by WhatsApp's servers, encrypted — One tick; Held on the server — Encrypted, waiting for a device, up to 30 days — Still one tick; Delivered — On at least one recipient device — Two grey ticks; Read — Displayed in an open chat on a recipient device — Two blue ticks; Failed — Could not be sent or delivered — A red triangle

Two rules tie the states together. A message is read only if it has been delivered ; there is no path from "sent" to "read" that skips delivery. And states never go back: a delivered message cannot become merely sent again.

Where the message lives in each state

WhatsApp says it does not keep users' messages in the ordinary course of providing the service : messages live on users' devices, not typically on its servers . The server copy exists only between "sent" and "delivered", and is deleted once the message is delivered . A message that cannot be delivered is kept, encrypted, for up to 30 days while delivery is retried , and deleted if it is still undelivered after that .

Public states and private ones

WhatsApp's apps and servers certainly have more internal states than the ones above: queued for one device and not another, retrying, waiting for a key refresh. Those are not public, so this article does not name them as WhatsApp's. The simulations use their own event names, chosen for clarity, and say so.

Disappearing messages add an end state of their own: users choose how long sent messages stick around , and in 2021 WhatsApp offered 24-hour, 7-day and 90-day durations . View Once photos and videos disappear from the chat once opened .

10. What the ticks mean

The ticks are the most-watched user interface in messaging and the most misread. Meta's developer documentation for the WhatsApp Business Platform gives the official meaning of each status a message can have, and the WhatsApp interface element that corresponds to it. That reference is written for businesses tracking their own messages, but the statuses are the same ones the apps display.

• One tick: sent. The message was sent successfully from WhatsApp's servers . It says nothing about the recipient yet.
• Two grey ticks: delivered. The message was delivered to the recipient's device . Not read: delivered.
• Two blue ticks: read. The message was displayed in an open chat thread on the recipient's device .
• A red triangle: failed. The message could not be sent or delivered to the device .
• A blue microphone: played. A voice message has been played for the first time .

And the clock you see before the first tick? It is part of the app, and its meaning is easy to infer: the message has not left the phone yet, because WhatsApp depends on a data connection the user supplies . But none of the official pages we could read defines it, so this article describes it from how sending works rather than quoting WhatsApp.

Read receipts

Read receipts are a privacy setting each user controls, listed with last seen and online, profile photo and the others . With them off, a recipient can read a message and the sender still sees two grey ticks. That is the single most important caveat about blue ticks: their absence proves nothing. WhatsApp's privacy policies describe message receipts as information other users can see, depending on your settings .

What we could not verify

WhatsApp's Help Center articles on check marks and read receipts render their text with scripts and served only their titles to every request made for this study . Three widely repeated rules come only from there, so this article reports them as undocumented here rather than as fact: that in groups the ticks turn blue only after every participant has read the message ; that turning off your own read receipts also stops you seeing other people's; and the exceptions for groups and voice messages . Meta's reference confirms only that the statuses themselves apply to recipients in groups .

11. Delivery acknowledgements

"It arrived" means different things depending on who says it. A message on its way from Priya to Sam is acknowledged at least four times, by four different parts of the system, and each acknowledgement covers a different stretch of the journey.

• Transport. Underneath everything, a reliable transport such as TCP acknowledges bytes and retransmits the ones that go missing . This proves only that the bytes reached the other end of this connection: WhatsApp's server, not Sam.
• Server acceptance. WhatsApp's servers have the message: one tick, "sent successfully from our servers" .
• Device delivery. One of Sam's devices has received it: two ticks .
• Read. It was displayed in an open chat on Sam's device: blue ticks .

Meta's Business Platform documentation makes the separation explicit: each outgoing message can produce up to three separate status notifications, one each for sent, delivered and read . And because read implies delivered, the two can arrive together, for example when Sam already has the chat open as the message lands .

Each acknowledgement leaves a question open

A transport acknowledgement does not mean the server processed the message. A server acknowledgement does not mean any device has it. A delivery acknowledgement does not mean the person saw it, and it may come from Sam's laptop while his phone still has nothing. A missing read acknowledgement means nothing at all, because read receipts can be off .

SMS has the same ladder. Its standard says a delivery report from the Service Centre only confirms that the centre received the message, not that it reached the destination , while a report from the handset confirms the phone received it, not that the user saw it .

How WhatsApp's apps encode these acknowledgements on the wire, and whether receipts are themselves end-to-end encrypted messages, is not documented in the sources used here.

12. When the recipient is offline

Sam's phone is switched off on a flight. Priya sends anyway. Her phone does not need his to be reachable: once it has a session with his device, it can send immediately . The message goes to WhatsApp's servers, and stops there.

What the server does

If the recipient's device is online, WhatsApp delivers the message directly. If it is offline, WhatsApp stores the encrypted message for up to 30 days and sends a push notification . WhatsApp's terms say the same: undelivered messages are stored on its servers for up to 30 days . The copy stays encrypted, and WhatsApp says it cannot see the contents . Meanwhile Priya sees one tick, because the message has reached WhatsApp's servers and nothing more has happened.

When Sam lands and his phone connects, the server delivers the stored copy and deletes it: once a message has been delivered, it is deleted from WhatsApp's servers . Meta's multi-device post says the same about the design in general: messages are not stored on the server after delivery . Sam's phone reports delivery, and Priya's single tick becomes two .

The 30-day limit

A message that is still undelivered after 30 days is deleted . If Sam's phone stays away longer than that, the message never reaches him and never reaches the delivered state . What Priya's chat shows afterwards is not documented in the sources used here; in the simulation the single tick simply stays, because no delivery report can ever come. Separately, WhatsApp deletes accounts whose phone has not been online for 120 days .

Why store at all, and why only for 30 days?

Storing messages for offline devices is what makes WhatsApp feel like texting rather than a phone call: the recipient does not have to be there. Signal's servers do the same, queuing end-to-end encrypted messages only for devices that are temporarily offline , and Signal's multi-device specification assumes a server that stores messages only until devices fetch them . A time limit bounds how much undelivered ciphertext the service holds and for how long. Whatever WhatsApp's own reasons, the documented outcome is a short-lived, encrypted mailbox rather than an archive.

This is the same store-and-forward idea SMS is built on , with one difference that matters: an SMS centre holds readable text ; WhatsApp's servers hold ciphertext.

13. When the sender is offline

Now flip it: Priya is in a lift with no signal when she presses Send. Nothing reaches WhatsApp, because nothing can. WhatsApp depends entirely on a data connection the user brings , so a message cannot leave a phone that has none .

Local state, not server state

This is a different situation from chapter 12 in one important way: the message is not on any server. It exists only on Priya's phone, already encrypted if her app has got that far, and the chat shows a clock instead of a tick. The servers do not know the message exists, so no 30-day clock is running, no push notification goes to Sam, and nothing will arrive if Priya's phone is lost before it reconnects.

When the phone reconnects, the app sends the message as normal and the ticks appear. That an app queues and later sends a message is how every messaging app behaves; the exact behaviour, including how long WhatsApp's app keeps trying, is not described on any official page that could be read for this study .

The awkward middle

The hardest case is a connection that drops during sending. Suppose the message reaches the server, but the connection fails before the server's acknowledgement gets back to the phone. From the phone's point of view this looks exactly like the message being lost on the way. The only safe thing to do is send again, and the only way that does not create a duplicate is for the server to recognise the repeat. Chapter 18 explains the standard technique.

The lab's retry and duplicate detection follow the standard technique (a sender-chosen message ID that the server recognises). WhatsApp has not documented how its own app and servers do this.

14. Multi-device: one account, several devices

Until 2021, WhatsApp on a computer was a mirror of the phone: web, desktop and Portal clients kept a persistent connection to the phone and only displayed what it had . The phone did all the encryption, and if its battery died the computer stopped working.

Multi-device changed the model. Each device now has its own identity key . Up to four devices can be linked to a primary phone , since April 2023 including another phone , and each one connects to WhatsApp independently, with personal messages, media and calls still end-to-end encrypted .

What that means for every message

Because every device has its own keys, the sender encrypts each message separately for each of the recipient's devices, using the session with that device : client-fanout . The sender's own other devices get copies too, so the conversation appears on all of them . This is the price of multi-device: one message to someone with a phone and three linked devices, sent from a phone with one linked laptop, is five encryptions.

Linking a device

Linking requires two signatures: the primary signs the new device's identity key, and the new device signs the primary's . With QR linking, the new device shows its public identity key and an ephemeral linking secret in the QR code, and that secret never goes to WhatsApp's server . The linking data is authenticated with that secret , so only the phone that scanned the code can complete it. An alternative is an 8-character code , which bootstraps a key exchange that yields a strong AES-256 key .

History and settings

Right after linking, the primary encrypts a copy of messages from recent chats for the new device , so recent history appears, not necessarily all of it . Application state such as contact names, archived chats and starred messages also syncs across devices, end-to-end encrypted ; it excludes message content and keys , and the server stores it only to relay it, without keys to decrypt it .

When devices go away

A companion can log itself out, be logged out by the primary, or be logged out by the server . If the primary phone is inactive for a long period, WhatsApp logs out all linked devices ; the exact period is not stated on any official page that could be read . Reinstalling WhatsApp on the primary regenerates its identity key and revokes every companion at once .

15. Group messaging

A group of 50 people, each with a phone and a laptop, would cost a sender 99 encryptions per message if groups worked like one-to-one chats. WhatsApp's groups instead use Sender Keys, a scheme from the Signal Messaging Protocol, distributed over the pairwise sessions that already exist . Groups can have up to 1000 members, according to WhatsApp's current groups page (a 2022 announcement said 1024 ; the two official figures differ ).

How Sender Keys work

• The first time a member sends to the group, their phone generates a Sender Key: a random 32-byte chain key and a signature key pair .
• It sends that Sender Key to every member device, encrypted individually over each pairwise session .
• For every later message, it derives a message key from the chain key, moves the chain forward, encrypts with AES-256 in CBC mode , and signs the ciphertext .
• It uploads one ciphertext, and the server fans it out to all participants .

Forward secrecy comes from the hash ratchet on the sender's chain key . When a member leaves, every participant discards their Sender Key and starts over , so someone who has left cannot read what comes next.

The trade-off

This is the reverse of one-to-one chats: server-side fan-out instead of client-side fan-out . It is far cheaper for the sender, but a Sender Key chain ratchets only by hashing, with no Diffie–Hellman step per message. A leaked chain key would therefore expose that sender's later group messages until the key is replaced, for example when a member leaves . How the server performs the fan-out internally is not documented .

Groups and what the server knows

Group names and descriptions are not end-to-end encrypted, so WhatsApp can see them . Status posts reuse the group protocol . Community announcement groups go further: members can only react, and reactions use a separate add-on key, encrypted twice . Signal, for comparison, says its service keeps no record of group memberships, titles or avatars .

16. Images, videos and attachments

A holiday video is too big to encrypt separately for every device and push through the message path. WhatsApp separates the file from the message about it.

• For each attachment, the sender's phone generates a fresh 32-byte AES-256 key and a fresh 32-byte HMAC-SHA256 key .
• It encrypts the file with AES-256-CBC and a random IV, and appends an HMAC-SHA256 of the ciphertext .
• It uploads the encrypted file to a blob store .
• It sends an ordinary end-to-end encrypted message containing the two keys, a SHA-256 hash of the encrypted blob and a pointer to it .
• Each receiving device downloads the blob, checks its hash, checks the MAC, and only then decrypts .

All large attachments are handled this way: video, audio, images and files . Since the keys travel inside the per-device message while the blob is uploaded once, one encrypted upload serves every recipient device; only the small message carrying the keys is fanned out .

Media has its own lifecycle

The message about a photo is deleted from the servers once delivered, like any message. The photo itself follows different rules. When media is forwarded, WhatsApp keeps it temporarily, encrypted, so that further forwards are more efficient ; WhatsApp's European Region policy says media sent in a message is stored encrypted for up to 30 days , and WhatsApp says it cannot see it . So the encrypted blob can outlive the message that pointed to it . Where the blob store runs and whether a CDN serves it is not documented .

On the phone, received photos, video and audio are saved to local storage by default, which users can turn off . Documents can be up to 2 GB .

17. Voice messages and calls

A voice message and a voice call sound alike and work completely differently.

A voice message is a recorded file. It is encrypted and sent like any attachment (chapter 16), it can wait on the server for an offline recipient, and once it has been played the sender sees a blue microphone .

A call is live audio or video. There is nothing to store and deliver later: if nobody answers, it is a missed call. Personal voice and video calls are end-to-end encrypted , with their own key handling:

• The caller makes sure it has a pairwise session with each of the callee's devices .
• It generates a separate random 32-byte SRTP master secret for each callee device and sends each device its own, end-to-end encrypted, with the incoming-call message .
• Whichever device answers, the call media is encrypted with SRTP under that device's secret .
• The secret is kept only in memory, only for the length of the call . WhatsApp's servers never have it .

Group calls

Group calls change keys as people come and go. Keys are reset whenever a participant joins or leaves : the server picks one active participant as key distributor , which generates a new 32-byte secret and sends it, end-to-end encrypted, to each participant . The old key stays usable for up to 5 seconds so media already in flight can still be decrypted . Group calls can have up to 32 people . The servers cannot access the audio or video , but they do store the call's state, such as the participant list and initiator, and media metadata such as resolution .

What is not documented

The SRTP cipher suite, how media is relayed, and how call signalling is routed are not described in the whitepaper , and whether calls go peer to peer or through WhatsApp's relays is not described on any official page that could be read . WhatsApp does document that clients exchange network information during a call to adjust audio and video quality , and that on iOS a call can switch network interface when the current one is limited .

18. How WhatsApp handles unreliable networks

Mobile networks drop connections in lifts, trains and crowds. A messaging system has to keep three promises anyway: nothing silently lost, nothing shown twice, and nothing stuck forever. What WhatsApp documents here is mostly the shape of the cryptography; the retry machinery is the textbook part, and this chapter keeps the two apart.

What is documented

• Messages wait for devices. An offline device's messages are stored, encrypted, for up to 30 days while delivery is retried .
• Keys tolerate loss and disorder. The ratchet lets messages arrive late, out of order or not at all without breaking decryption . Signal's Double Ratchet does this by carrying the message number and previous chain length in every header , and bounds how many skipped keys a receiver will store ; whether WhatsApp applies such a bound, and its value, is not documented .
• Reconnection is cheap. The transport is designed for fast connection setup and resumption , and the device's authentication key lets it reconnect without the user typing a password or code .
• Calls adapt. Clients exchange network information during calls to adjust quality , and WhatsApp tracks calls that end by disconnection and the conditions of the network link .

The duplicate problem (general reasoning)

When a phone sends a message and hears nothing back, it cannot tell whether the message or the acknowledgement was lost. A timeout does not mean the operation did not happen . Re-sending is the only way to avoid losing the message, and re-sending is safe only if the receiver can recognise a repeat.

The standard answer is idempotency: an operation that can be retried with no additional side effects . Amazon's engineering guidance recommends a unique, caller-provided request identifier, so that repeats with the same identifier are treated as duplicates , and HTTP's specification says requests can be retried automatically only if they are idempotent or the client can detect whether the original was applied . Queues that promise at-least-once delivery may deliver more than one copy , which is why their users are told to make processing idempotent . Retries need restraint too: during an outage they add load, so clients back off between attempts and add random jitter .

Other messaging systems document versions of this. SMS has a flag telling the Service Centre to reject a resubmission with the same message reference . Telegram's secret chats drop any message whose sequence number has already been seen .

WhatsApp has not documented how its app retries, how long it keeps trying, or how its servers recognise a repeated message. The lab shows the general technique. Bit Culled's NATS deep dive shows the same at-least-once problem, and how a message broker handles redelivery, in a system that documents it fully.

19. Message ordering and synchronisation

Priya sends "I'm leaving now". Two seconds later, before it reaches him, Sam sends "Wait, where are you?". On Priya's screen, her message comes first. On Sam's, his might, if hers was slow to arrive. Neither screen is wrong. Each shows what it saw.

Why "first" is hard

Leslie Lamport's classic paper makes the point precisely: in a distributed system it is sometimes impossible to say which of two events happened first, so "happened before" is only a partial ordering . He defines it without physical clocks because real clocks are never perfectly accurate . His logical clocks have each message carry the sender's clock value, and the receiver advance its own clock past it , but he also warns that the order this produces can differ from what users perceive . Message queues reflect the same reality: Amazon's SQS standard queues make only a best-effort attempt to preserve send order .

What WhatsApp documents

WhatsApp publishes no ordering guarantee for chats in the sources used here. What it does document is that its encryption does not depend on order: messages can arrive late, out of order or not at all without breaking decryption . For synchronised settings it documents something stronger: application-state changes are grouped into patches that move a collection from one version to the next atomically, and the server keeps an ordered queue of patches , so every device applies the same changes in the same order.

Other systems

Telegram's secret chats go the other way: messages must be interpreted in their original order, using sequence counters handled independently of the server, to guard against reordering, replay and omission , and a gap in the sequence is treated as the server leaving messages out . Signal's earlier groups, managed by clients, could end up with members holding diverging views of a group when updates raced .

The lab compares two simple ordering rules, by arrival and by sender's clock, to show the problem. It is not a description of how WhatsApp's apps order messages, which is not documented.

20. Message privacy and metadata

End-to-end encryption protects what Priya says. It does not hide that she said something, to whom, when, or from where. That second category is metadata, and WhatsApp's privacy policies describe collecting a good deal of it.

Content

Messages, calls and media in messages are end-to-end encrypted, against third parties including WhatsApp ; messages are encrypted before they reach WhatsApp's servers, so it cannot see them . Precise location shared in a chat is encrypted too .

What WhatsApp does collect

• Usage and log information: the time, frequency and duration of activities and interactions , whether you are online and when you were last seen , and, in the European Region policy, timestamps of when you send and receive messages and calls .
• Device information: hardware model, operating system, battery level, signal strength, app version, mobile network .
• Connection information: phone number, operator or internet provider, language, time zone and IP address . Even without location features, WhatsApp estimates general location from IP addresses and area codes .
• What delivery needs: the phone numbers, times and dates of messages and calls, and call durations, kept for as long as needed .
• Things that are not encrypted: profile picture, "about" text, group and community names and descriptions .

Put together, WhatsApp's servers can see who is communicating with whom, when, from which IP address and network, and whether they are online, while message content stays encrypted . The connection to WhatsApp is encrypted and hides the user's identity from network observers , but traffic analysis and IP addresses can still reveal who is talking, a limit the Noise specification itself points out .

Three important exceptions

Businesses. WhatsApp works with businesses that use Meta or other providers to store and manage their WhatsApp messages , and a business may give such a provider, which may be Meta, access to its conversations . WhatsApp does not class chats with businesses using Meta's Cloud API as end-to-end encrypted , and a chat's status cannot change without a visible system message .

Reports. You can report messages to WhatsApp , and a report collects information about both users . This is a route by which content reaches WhatsApp despite encryption: the reporter's own phone has the decrypted messages and submits them . How many messages a report includes is not stated on any page that could be read .

Backups. End-to-end encryption covers backups in iCloud or Google Drive only if you turn on encrypted backups ; a backup made without it is protected by the cloud provider, not WhatsApp's encryption . With it on, neither WhatsApp nor the provider can read the backup , which is protected by a password, a 64-digit key or, since October 2025, a passkey .

How encrypted backups keep the key away from WhatsApp

Before 2021, cloud backups were protected by the storage provider rather than end to end . With encrypted backups, the phone encrypts the backup under a random 256-bit key generated on the device . If the user chooses a password, the key is stored in an HSM-based Backup Key Vault using the OPAQUE protocol, so the vault never learns the password , and the vault limits password attempts and makes the key permanently inaccessible after too many failures . A 64-digit key is never sent to the vault at all . Encrypted backups are currently supported only on the primary device .

Even settings sync hides sizes

App-state sync (chapter 14) pads changes randomly to hide their size from the server, and sends record identifiers as HMACs so the server cannot tell which record changed . It is a small example of a broader point: hiding metadata takes deliberate work beyond encrypting content.

21. Message authentication and security verification

End-to-end encryption assumes Priya's phone is encrypting to Sam's real keys. But Priya's phone got those keys from WhatsApp's server. If the server, or someone who controlled it, handed out its own key instead, it could decrypt, read and re-encrypt every message: a man-in-the-middle attack. Signal's X3DH specification is direct about it: without authenticating identity keys out of band, there is no cryptographic guarantee of who you are talking to .

Security codes and QR codes

WhatsApp lets users verify keys by scanning each other's QR code or comparing a 60-digit number on their two phones . A match confirms that no third party, WhatsApp included, is in the middle . The QR code contains a version, both users' identifiers and the public identity keys (or their SHA-512 hashes) of all devices on both sides .

The 60-digit number is two 30-digit fingerprints, one per person, each covering all of that person's device identity keys . Each fingerprint sorts the keys, iterates SHA-512 over them and the user's identifier 5,200 times , then reads the first 30 bytes of the result as six 5-digit groups . Since multi-device, a security code represents the combination of all of a person's devices , so linking a new device changes it.

Key transparency

Comparing codes in person does not scale: a group of 100 people has 4,950 pairs to check . So WhatsApp also runs key transparency: an append-only Auditable Key Directory mapping accounts to public keys , in which every change is recorded in a public audit record anyone can verify . Changes are batched into epochs (every 5 minutes, per the 2023 whitepaper ), the sequencer signs each root hash, and the key that verifies those signatures ships inside the app, guarding against the server showing different users different directories . If a key is missing or different in the directory, the app tells the user to verify manually . Key transparency complements QR-code verification; it does not replace it .

The lab computes real SHA-512 fingerprints following the whitepaper's steps. The whitepaper does not specify exactly which bytes go into each iteration, so its numbers will not match the codes in the app.

22. What happens when something goes wrong?

Most of the time nothing goes wrong, and the ticks appear within a second. This chapter is about the rest of the time. Each scenario below runs on the same simulation engine as the rest of the page, so the outcome follows from the documented rules rather than from a script of results.

Scenario — What happens — Sender sees; A · Recipient's phone offline — Held encrypted on the server, up to 30 days, then delivered on reconnect — One tick, then two; B · Sender loses connection — Waits on the sender's phone; the server never sees it — Clock, then ticks; C · Phone offline, linked desktop online — The desktop's own copy is delivered and read; the phone's waits — Two ticks, then blue; D · Read receipts off — Delivered and read, but reading is not reported — Two grey ticks; E · Delivery delayed — Every step happens, in order, later — Clock for longer; F · Undelivered for 30 days — The server deletes the copy — One tick (what the app shows next is not documented); G · Connection drops before the acknowledgement — The app resends; the server must recognise the repeat — Clock, then ticks (illustrative)

Patterns in the failures

Three things recur. Location decides behaviour: a message on the sender's phone (B) and a message on the server (A, F) fail differently, and the clock and the single tick tell you which. Devices are independent: C works because each device has its own copy and its own connection . The sender's view is a summary: "two ticks" in C hides the fact that the phone has not got the message yet, and "two grey ticks" in D hides that it has been read.

Signal's multi-device specification warns that higher-level protocols must cope with partial delivery to groups of recipients ; scenario C is the everyday version of that.

Blocking is a different case: blocking a contact stops their messages and calls from reaching you . What the blocked sender's ticks show is not documented in the sources used here .

23. Engineering trade-offs

This chapter is engineering analysis. It describes tensions visible in WhatsApp's documented design and how the documented choices resolve them. It does not claim to know why WhatsApp's engineers chose what they did, except where WhatsApp or Meta has said so.

Reliability versus latency

Holding messages for offline devices makes delivery reliable without requiring both phones to be online at once. The cost is that "sent" and "delivered" become separate, sometimes distant, events, which is exactly why there are two ticks. A design that waited for the recipient before confirming anything would feel slower and fail more often.

Privacy versus observability

A server that cannot read messages cannot debug them, search them or filter them. WhatsApp's design keeps content opaque while still handling the metadata needed to deliver messages and storing troubleshooting information for up to 90 days . Even settings sync pads updates and hides record identifiers from the server . Signal pushes further, keeping group membership off its servers entirely , and argues that the usual alternative, group state in a plaintext server database, lets the server and anyone who compromises or subpoenas it see everything .

Offline delivery versus storage minimisation

Every hour a message waits on a server is an hour it exists somewhere other than the two phones. WhatsApp's documented compromise is a bounded, encrypted mailbox: up to 30 days, then deletion , and deletion on delivery . Media is a separate case, kept encrypted for up to 30 days to make forwarding efficient .

Multi-device convenience versus key-management complexity

Giving every device its own keys means a dead phone no longer silences the laptop. It also means every message is encrypted once per device , device lists must be signed, distributed and expired , stale lists need repairing after the fact , and history must be re-encrypted for each new device . Telegram's FAQ makes the opposite argument: that restoring history on a new device has no elegant solution under end-to-end encryption, which it uses to justify cloud chats .

Simple ticks versus distributed reality

Three icons summarise a message's state across a sender, a server and up to five recipient devices. That summary is very useful, and necessarily lossy: two ticks can mean "on the laptop, not the phone", and grey ticks can mean "read, with receipts off". The design choice that keeps it honest is that each tick reports a fact from a specific place , rather than a guess about what the recipient did.

Group efficiency versus group forward secrecy

Sender Keys turn one encryption per member device into one per message , at the price of a weaker ratchet: a leaked chain key exposes later messages until the key is replaced .

Bit Culled's Netflix study shows a very different set of trade-offs: a system built to move huge volumes of non-secret data as close to the user as possible. The PostgreSQL deep dive covers the durability guarantees a database makes, which WhatsApp's design deliberately avoids needing for message content.

24. WhatsApp compared with other messaging models

Each system below is described only by what its own documentation says. Where a row says "not documented", that is literally the case for the sources read for this article, not a hint that the answer is bad.

End-to-end encrypted by default — Yes, personal chats and calls — Yes — No — Yes, when chosen — No end-to-end layer — No; Server can read content — No — No — Not stated — No — Held readable while pending — Yes; Kept on the server after delivery — No; undelivered up to 30 days — No; queued only for offline devices — Stored in the cloud — Deleted when acknowledged — Not specified after delivery — Not documented; Several devices — Up to four linked — Multi-device — Many, synced — Device-specific — Not documented — Not documented; Groups end-to-end encrypted — Yes, Sender Keys — Yes — No — No, one-to-one only — Not documented — No

Reading the table

WhatsApp and Signal use the same protocol family and the same broad model: devices encrypt, servers hold ciphertext briefly. They differ most in what the server knows about the people. Signal says it can provide only the dates an account was created and last connected , and lists messages, contacts, groups and profile names among the data it does not have ; its "sealed sender" moves even the sender's identity inside the encryption . WhatsApp's policies describe collecting much more metadata (chapter 20).

Telegram offers two different products under one name. Cloud chats use client-server encryption and are stored encrypted in the Telegram cloud , which is what lets them sync instantly across many devices ; Telegram stores cloud-chat data across jurisdictions with decryption keys kept apart . Secret chats add end-to-end encryption but are tied to the device they started on and lost on logout , and groups are never end-to-end encrypted .

SMS is store-and-forward through the operator , with no end-to-end encryption in the standard . Whether operators keep messages after delivery is not specified by the standard and varies .

A server-readable chat service encrypts connections with TLS and stores messages in plaintext: easy server-side features and access control, and a server that can see all the data . Most email and many workplace chat tools work this way.

25. The complete message journey

Everything in this article in one place. Type a message and send it from Mumbai to London. Then break things: take either phone offline, link a desktop, turn read receipts off, slow the network, skip ahead 30 days, or load one of the failure scenarios. Every step is listed in the timeline with its logical time, where it came from and went to, what was carried, how the sender's ticks changed and which sources document it. Step backwards and forwards with the controls or the arrow keys, and switch on "Show encrypted payload" to see what the servers handle.

The lifecycle in one paragraph

Priya's phone encrypts "Hey, are you coming?" separately for each of Sam's devices and her own , and sends the ciphertexts inside an encrypted connection to WhatsApp . WhatsApp's servers hold them, encrypted : one tick . Each of Sam's devices that is online receives its copy, which the server then deletes ; a device that is offline gets a push notification and its copy waits for up to 30 days . The first device to report delivery turns one tick into two . When Sam opens the chat, with read receipts on, the ticks turn blue . At no point does WhatsApp hold a key that can read the message .

What to remember

• Encryption happens on the phone, once per device, before anything is sent.
• The server sees envelopes and metadata, not content.
• Each tick is a fact from a different place: the server, a device, an open chat.
• Offline is normal: the server holds encrypted messages for up to 30 days.
• Absence of evidence is not evidence: grey ticks can mean "read, receipts off"; one tick can mean "phone off for a week".

If you enjoyed following a request through a whole system, Bit Culled's AI deep dive does the same for a prompt sent to a language model, and the Kubernetes deep dive for a container from YAML to running Pod.

Technologies

• Signal Protocol: The basis of WhatsApp’s end-to-end encryption: session setup, the double ratchet and Sender Keys for groups. WhatsApp says its library is based on libsignal-protocol-java.
• Noise Protocol Framework: Noise Pipes with Curve25519, AES-GCM and SHA256 encrypt every connection between the app and WhatsApp’s servers.
• SRTP: Encrypts call media under a per-device master secret that WhatsApp’s servers never have.
• Auditable Key Directory (AKD): WhatsApp’s key transparency: an append-only directory of public keys with publicly verifiable audit records, implemented in an open-source Rust crate.

Sources

1. ETSI TS 123 040 V18.0.0 — Technical realization of the Short Message Service (SMS) (3GPP TS 23.040 version 18.0.0 Release 18) — ETSI / 3GPP, 2024-05
2. Telegram FAQ — Telegram, undated (current)
3. End-to-End Encryption, Secret Chats — Telegram (core.telegram.org), undated (current)
4. Sequence numbers in Secret Chats — Telegram (core.telegram.org), undated (current)
5. RFC 791: Internet Protocol — IETF / RFC Editor, 1981-09
6. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification — IETF / RFC Editor, 2017-07
7. RFC 9293: Transmission Control Protocol (TCP) — IETF / RFC Editor, 2022-08
8. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — IETF / RFC Editor, 2018-08
9. The Noise Protocol Framework (Revision 34) — noiseprotocol.org (Trevor Perrin), 2018-07-11
10. Web Cryptography Level 2 (W3C First Public Working Draft) — W3C, 2025-04-22
11. NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC — NIST, 2007-11
12. Making retries safe with idempotent APIs — Amazon Builders' Library (Malcolm Featonby), undated
13. Timeouts, retries, and backoff with jitter — AWS Builder Center (Marc Brooker), 2019-12-05
14. Amazon SQS at-least-once delivery — AWS documentation, undated (current)
15. Amazon SQS standard queues — AWS documentation, undated (current)
16. RFC 9110: HTTP Semantics — IETF / RFC Editor, 2022-06
17. Time, Clocks, and the Ordering of Events in a Distributed System — Leslie Lamport, Communications of the ACM, 1978-07
18. Grand jury subpoena for Signal user data, Central District of California (again!) — Signal, 2021-10-28
19. Search warrants for Signal user data, Santa Clara County — Signal, 2024-08-08
20. Technology preview: Sealed sender for Signal — Signal blog (jlund), 2018-10-29
21. Signal Terms & Privacy Policy — Signal, undated (current)
22. Technology Preview: Signal Private Group System — Signal blog (jimio), 2019-12-09
23. The Sesame Algorithm: Session Management for Asynchronous Message Encryption (Revision 2) — Signal (Moxie Marlinspike, Trevor Perrin), 2017-04-14
24. Status messages webhook reference — Meta for Developers (WhatsApp Business Platform), undated (current)
25. Webhooks components — Meta for Developers (WhatsApp Cloud API), undated (current)
26. WhatsApp Encryption Overview — Technical white paper (Version 9) — WhatsApp, 2026-02-25
27. Signal >> Documentation (specifications index) — Signal, undated
28. The X3DH Key Agreement Protocol (Revision 1) — Signal, 2016-11-04
29. The PQXDH Key Agreement Protocol (Revision 3) — Signal, 2023-05-24 (updated 2024-01-23)
30. The Double Ratchet Algorithm (Revision 4) — Signal, 2025-11-04
31. Security Features, Safety Tools & Tips | WhatsApp — WhatsApp, undated
32. How WhatsApp enables multi-device capability — Engineering at Meta, 2021-07-14
33. Deploying key transparency at WhatsApp — Engineering at Meta, 2023-04-13
34. WhatsApp Key Transparency Overview — Technical white paper (Version 1) — WhatsApp, 2023-08-22
35. How WhatsApp is enabling end-to-end encrypted backups — Engineering at Meta, 2021-09-10
36. Security of End-To-End Encrypted Backups — WhatsApp Security Whitepaper (Version 3) — WhatsApp, 2026-10-08
37. How Device Verification protects your WhatsApp account — Engineering at Meta, 2023-04-13
38. WhatsApp Privacy Policy (outside European Region and UK) — WhatsApp LLC, effective 2021-01-04
39. End-to-End Encrypted Backups on WhatsApp — WhatsApp Blog, undated on page (Newsroom copy 2021-10)
40. We're Making it Easier to Encrypt Your WhatsApp Chat Backups — Meta Newsroom, 2025-10
41. View Once Photos and Videos on WhatsApp — WhatsApp Blog, 2021-08-03
42. More Control and Privacy with Default Disappearing Messages and Multiple Durations — WhatsApp Blog, 2021-12-06
43. One WhatsApp account, now across multiple phones — WhatsApp Blog, 2023-04-25
44. Communities Now Available! — WhatsApp Blog, 2022-11-03
45. WhatsApp Privacy Policy (European Region) — WhatsApp Ireland Limited, effective 2026-07-02
46. Two Billion Users -- Connecting the World Privately — WhatsApp Blog, 2020-02-12
47. End-to-End Encrypted Backups on WhatsApp — Meta Newsroom, 2021-10
48. WhatsApp Terms of Service — WhatsApp LLC, effective 2021-01-04
49. About WhatsApp — WhatsApp, undated (current site)
50. Message privately (Privacy) — WhatsApp, undated (current site)
51. Connect your way (Messaging) — WhatsApp, undated (current site)
52. Connect and get more done with groups — WhatsApp, undated (current site)
53. Connection is a call away (Calling) — WhatsApp, undated (current site)