Does WhatsApp or WeChat Destroy Hidden Data in Photos? We Tested Every Major Chat App

Short answer: send a photo the normal way on WhatsApp, Telegram, WeChat, WeChat Moments, iMessage or Instagram and the app recompresses it — a re-encoded, resized JPEG. That recompression destroys ordinary hidden data, because classic steganography lives in the pixel bits the re-encode overwrites. The usual fix is to send the image as a file/document so the original bytes survive.

WaxSeal is built for the other case — where you want to just send the photo normally and have it still work. So we tested exactly that: the normal, compressed “send as photo” path on every major chat app. Here is what survived.

Why the normal photo path kills hidden data

Ordinary image steganography (LSB — least-significant-bit) hides your secret in the lowest bits of the pixel values. It is invisible, and it is fragile: any re-encode rewrites those bits. When a chat app takes your PNG, resizes it to ~1600–2560 px on the long edge and saves it as a fresh ~70–85% JPEG, the hidden bits are gone. This is why “hide data in a photo” tutorials quietly tell you to send the result as a document, never as a photo.

That works, but it depends on the sender remembering to bypass the normal path every time — and on a recipient who won’t just forward it as a photo. It is a workaround, not a property.

What WaxSeal does differently — and why it’s a different class

Surviving compression is the visible part. The reason it matters is what sits behind the mark. WaxSeal does not put the secret in the pixels at all. The photo carries only a small sealed reference, embedded as a robust watermark built to survive the compression and resizing chat platforms apply. The secret itself is encrypted and never travels in the image. That separation is what makes the rest possible:

• The keys live in the chip, and never leave it. Every device’s private keys are generated and used inside Apple’s Secure Enclave — the hardware security chip. Private-key operations happen inside the hardware boundary; the key is never exported, never synced, never seen by us or by the vault. There is no key sitting in a file to steal.
• Asymmetric, wrapped per recipient. Each approved recipient device gets the content key wrapped to its own public key (HPKE / RFC 9180, over the Secure Enclave’s own ECDH). The vault stores only ciphertext and opaque wrapped keys; it cannot decrypt anything, and it cannot add a recipient without a detectable break of a sender signature.
• Only the intended recipient’s device can open it — and only they can trigger it. Access is bound to the recipient’s registered device, and opening requires Face ID or Touch ID to release that device’s Secure Enclave key locally, on that device. Their biometric never leaves the phone and never reaches us — we don’t hold, transmit or match a face; the biometric is simply the local switch that unlocks the hardware key. Wrong device, or the right device without the owner’s Face ID, opens nothing.
• Content encryption is AES-256-GCM, with each recipient’s key wrapped over the Secure Enclave’s own P-256 key agreement (HPKE). AES-256 is the part that stays hard even against a future quantum attacker; the key exchange is P-256 today because that is what runs inside Apple’s hardware and keeps the private key on the chip. A post-quantum key-exchange layer is something we intend to add, without putting a version number on it here — we would rather ship the hardware-bound guarantee now, and add post-quantum deliberately when it can be done without giving up the Secure Enclave, than claim a resistance the current suite doesn’t have.
• You keep control after it leaves your hands. Revoke, set an expiry, cap the number of reads, or require a PIN — even after the photo has been sent. These stop future authorized opens; they cannot un-show what a recipient has already opened and screenshotted, and we don’t pretend otherwise.

The practical consequence: you send the photo the normal way, on whatever app you already use, and only the person you chose — on the device you approved, behind their own Face ID — can ever open it. No “send as file” ritual, no link for a scanner to fetch, no plaintext anywhere but on the two ends.

The test matrix

Method: seal a photo in WaxSeal, send it through each app on its default “send photo” path (the one that recompresses), then open the received image on an approved recipient device.

✓ survives = the received, recompressed photo still opened on the recipient device.

Every “✓ survives” row above is a photo sent the normal, compressed way — not sent as a file. That is the whole point: with ordinary hidden data those same sends would have destroyed the payload.

The row that matters most is WeChat. WeChat, and WeChat Moments (朋友圈) above all, is the internet’s byword for brutal image recompression — it shifts colours, turns gradients into visible banding, evaporates fine detail, and compresses harder the larger your image is. Developers have written whole open-source libraries and “survives WeChat’s re-compression” tools for the sole purpose of getting an image through it intact. Weibo, Instagram feed and Facebook feed posts are in the same brutal class — public-feed uploads are where recompression is worst. Those are exactly the platforms that shred ordinary hidden data — and they are exactly the ones WaxSeal’s mark came through. If it survives WeChat Moments, the gentler one-to-one chats are the easy case.

The honest boundary

This is about compression and resizing — what a chat platform does to a normally-sent photo. It is not a claim that the mark survives anything: crop the image down, screenshot it and re-share the screenshot, or deliberately paint over it, and you are past what any photo-borne mark can carry. WaxSeal’s guarantee is scoped to what actually happens to a photo in normal use on these platforms, which is exactly compression and resizing.

Two more things worth stating plainly, because the short version would be false:

• An interceptor on the wire sees an ordinary photo and some metadata — no plaintext — but they do see that a photo was sent.
• Revoking, expiring or read-limiting stops future authorized opens. It cannot un-show what a recipient already opened and screenshotted.

When to use which

• Sending a secret to specific people, through the chat you already use, and keeping control after it leaves → that’s WaxSeal. Send the photo normally; only approved devices open it; revoke or expire it later.
• Keeping your own long-term secrets (seed phrases, recovery codes) hidden in photos on your own devices → that’s StegoSafe, a personal vault. There the advice is the opposite of this article: keep the images lossless (original/file transfer) and split one secret across several photos, because a personal vault is for keeping, not for sending through chat.

WaxSeal turns an ordinary photo into a device-bound delivery channel — send it through any chat, and only approved recipient devices can open it. See how it works.