Abstract

Every time you send a photo through a messaging app or post it on social media, the platform quietly transforms it. Your 24-megapixel image may emerge downscaled, recompressed, stripped of metadata, and re-encoded with an entirely different quantization matrix. But which platforms treat your photos gently, and which put them through the digital equivalent of a paper shredder?

We analyzed 15 major platforms – iMessage, WhatsApp, Telegram, Signal, Discord, Facebook, Instagram, Twitter/X, Snapchat, TikTok, WeChat, LINE, LinkedIn, Reddit, and Facebook Messenger – documenting what each does to your JPEG images: output quality factors, resolution limits, metadata behavior, chroma subsampling, progressive encoding, and format conversion.

The results range dramatically. Twitter/X can pass through an original JPEG byte-for-byte under the right conditions. WeChat compresses to an estimated quality factor of 53, obliterating fine detail. We also tested steganography survival for both stealth (Ghost) and robust (Armor) modes using Phasm, a client-side steganography app – including Armor’s new Fortress sub-mode, which survives even WhatsApp standard’s aggressive pipeline for short messages. The findings confirm: platforms that resize destroy most DCT-domain steganography, while those that only recompress offer varying degrees of hope. For a deeper dive into recompression mechanics, see Surviving JPEG Recompression.

Table of Contents

  1. Why This Matters
  2. Methodology
  3. The JPEG Recompression Pipeline
  4. The Master Comparison Table
  5. Platform-by-Platform Results
  6. Platform Tiers: From Preservation to Destruction
  7. The Math Behind the Damage
  8. What This Means for Steganography
  9. The Decision Flowchart
  10. The “Send as File” Workaround
  11. Practical Recommendations
  12. Conclusion
  13. References

Why This Matters

Whether you are a photographer wondering why your images look soft after sharing on WhatsApp, a privacy researcher investigating metadata behavior, or a steganography practitioner trying to preserve embedded data, the underlying question is the same: what do these platforms actually do to my photos?

The answer is more complicated than “they compress them.” Modern platforms apply a multi-layered pipeline: resolution downscaling, JPEG re-encoding with custom quantization tables, chroma subsampling conversion, metadata stripping, sharpening, progressive-to-baseline conversion, and even format transcoding to WebP or AVIF. Each operation transforms your image in ways that range from barely perceptible to visually obvious – and for steganography, each transformation is a potential death sentence for embedded data.

Methodology

Our analysis synthesizes data from four source categories:

  1. Published academic research – Dang-Nguyen et al.’s 2023 survey (arXiv 2302.12133), the ACM ARES 2022 Telegram steganography study, and the UC Denver forensic analysis of Discord (Nash, 2025).

  2. Open-source platform code – Discord’s Lilliput library, Signal’s Android compression source, and Meta’s Spectrum library (used by Facebook and Instagram).

  3. Community reverse engineering – the Photo Taco Podcast’s 80+ hours of quality testing, Compress-or-Die’s Twitter analysis, and Rifqi Fahmi’s Telegram compression research.

  4. Direct observation – JPEG quality factor estimation, resolution measurement, EXIF inspection, and quantization table analysis of output images.

For each platform, we measured: estimated output QF, maximum resolution, downscaling behavior, metadata handling, chroma subsampling, progressive vs. baseline encoding, post-processing (sharpening, etc.), format conversion, and bypass modes.

A note on quality factors: “QF” is not a universal standard. Different encoders (libjpeg, MozJPEG, Android’s built-in encoder) produce different quantization tables at the same nominal QF. Our reported values are approximate IJG-scale equivalents. Platforms with custom quantization tables (Facebook, Instagram, WhatsApp) may not map cleanly to any single QF number.

The JPEG Recompression Pipeline

Before diving into platform-specific results, it helps to understand what happens during JPEG recompression. This is the core destructive process that every platform (except pure passthrough) applies.

When a platform receives your JPEG image and re-encodes it, the following steps occur:

                flowchart TD
                    A["Your Original JPEG"] --> B["1. Entropy Decode
(Huffman)"]
                    B --> C["2. Dequantize DCT Coefficients
(multiply by quant matrix)"]
                    C --> D["3. Inverse DCT
(coefficients → pixels)"]
                    D --> E["4. Round Pixels to [0, 255]
⚠️ LOSSY STEP"]
                    E --> F["5. Forward DCT
(pixels → coefficients)"]
                    F --> G["6. Requantize with New Matrix
(divide + round)"]
                    G --> H["7. Entropy Encode
(Huffman)"]
                    H --> I["Platform's Output JPEG"]

                    style E fill:#ff6b6b,color:#fff
                    style G fill:#ff6b6b,color:#fff

The critical insight: even when a platform recompresses at the same quality factor, steps 4 and 6 introduce rounding errors. The pixel rounding in step 4 loses information permanently, and requantization in step 6 with potentially different quantization tables compounds the damage. This is why “re-saving a JPEG at the same quality” is not lossless.

Platforms that additionally resize the image insert an interpolation step between steps 4 and 5, mixing pixel values across the 8x8 block grid – catastrophically destructive to any block-aligned steganographic embedding.

The Master Comparison Table

Here is the complete platform comparison. This is the table that does not exist anywhere else on the internet in this level of detail.

Platform Est. JPEG QF Max Resolution Downscales? EXIF Stripped? Chroma Progressive? Sharpening? Format Convert? Ghost Survival Armor Survival
AirDrop Original Original No Preserved Original Original No No Yes Yes
Email (attachment) Original Original No Preserved Original Original No No Yes Yes
USB / file transfer Original Original No Preserved Original Original No No Yes Yes
iMessage (WiFi, Apple-to-Apple) Original Original No Preserved Original Original No HEIC to JPEG (non-Apple) Yes Yes
Twitter/X (web, <=5MB, <=4096px) Preserved 4096px display Only if >4096px All stripped 4:2:0 Always progressive No PNG to JPEG* Likely Likely
Telegram (<=2560px, as photo) 80-87 (typ. 82) 2560px If >2560px Stripped 4:2:0 Baseline No Non-JPEG to JPEG Possible Possible
Telegram (send as file) Original Original No Preserved Original Original No No Yes Yes
Discord 80 10MB (free) / 500MB (Nitro) CDN proxy resizes All stripped 4:2:0 Baseline No WebP/AVIF serving Possible Possible
Signal (HD) 95 (adaptive, min 50) 4096px If >4096px All stripped 4:2:0 Baseline No HEIC to JPEG Unlikely Unlikely
Signal (standard) 95 (adaptive, min 50) 1600px / 420KB target Yes All stripped 4:2:0 Baseline No HEIC to JPEG No No
Reddit ~80-85 20MB file limit Large images All stripped Likely 4:2:0 Unknown No WebP serving Possible Possible
Facebook Feed ~71-85 2048px If >2048px Most stripped Likely 4:2:0 Always (MozJPEG) Yes WebP serving Unlikely Likely*
Facebook Messenger ~72 2K (iOS) / 1K (Android) Yes Most stripped Unknown Yes Unknown No No No
LinkedIn ~70-85 36MP / ~1200px If >limits All stripped Likely 4:2:0 Unknown No PNG to JPEG Unlikely Unlikely
WhatsApp (HD) ~70-80 5120px If >5120px All stripped 4:2:0 Baseline No All to JPEG Unlikely Fortress*
WhatsApp (standard) ~50-60 960-1600px Yes (heavy) All stripped 4:2:0 Baseline No All to JPEG No Fortress*
WhatsApp (as document) Original Original No Preserved Original Original No No Yes Yes
TikTok ~70-80 1080px wide Yes GPS/device stripped 4:2:0 Unknown Unknown HEIC/WebP to JPEG No No
Snapchat ~50-70 1080x1920 Yes All stripped 4:2:0 Baseline Brightness adj. All to JPEG No No
iMessage (MMS) ~30-50 Carrier-limited Yes (heavy) Stripped 4:2:0 Baseline No HEIC to JPEG No No
Instagram Feed ~70-85 (ML adaptive) 1080px wide Always (most) All stripped 4:2:0 Yes (web) AI perceptual AVIF testing No No
WeChat ~53-75 ~1440px short side Yes (heavy) Stripped 4:2:0 Baseline Content filter Possibly WebP No No
LINE Unknown ~1200px Yes Likely stripped Unknown Unknown Unknown Unknown No No

* Twitter converts PNG to JPEG unless the image has alpha transparency.

* Fortress = Armor’s Fortress sub-mode (BA-QIM on DC block averages) auto-activates for short messages and survives aggressive recompression including WhatsApp standard (the default mode) and WhatsApp HD. See Surviving JPEG Recompression for technical details.

Key for survival columns: Yes = original bytes preserved. Likely = mild recompression, Armor + ECC has a reasonable chance. Possible = conditional on pre-sizing or other factors. Unlikely = heavy recompression, improbable even with ECC. Fortress = short messages survive via Fortress sub-mode. No = resize or aggressive compression destroys embedded data.

Platform-by-Platform Results

1. Twitter/X – The Most Permissive Platform

Twitter stands out as the most image-friendly major platform. Since December 2019, Twitter preserves the original JPEG quality for web uploads when two conditions are met: the file is 5MB or smaller and the resolution is 4096 pixels or less on any side. When these conditions hold, the JPEG bitstream is passed through without re-encoding.

When recompression does occur, Twitter applies QF 85 using standard IJG tables. All metadata is stripped. Baseline JPEGs are converted to progressive. PNGs are converted to JPEG unless they have alpha transparency.

Quality factor: 85 (or preserved under passthrough) | Resolution limit: 4096px display | Metadata: All stripped since 2015 | Chroma: Always 4:2:0

Steganography note: The best major platform for survival. Pre-sized JPEG under 5MB and 4096px passes through intact. Even QF 85 recompression is relatively gentle.

2. Telegram – The Conditional Preserver

Telegram is more interesting than most people realize. While it applies client-side compression with a typical QF of around 82 (80 on Android, up to 87 via the API spec), research from the ACM ARES 2022 conference uncovered a key finding: Telegram does not always re-compress images that are already JPEG and fall within its limits.

Images at resolution 2560x2560 or below, already encoded at approximately QF 80-82, may pass through without re-encoding. The ARES study demonstrated successful F5 steganographic extraction after Telegram transit, with approximately 81KB of embeddable data per 2560x2560 image.

Quality factor: 80-87 (typically 82) Resolution limit: 2560px (updated from earlier 1280px limit) Metadata: Stripped when sent as photo; preserved when sent as file Key behavior: “Send as file” mode preserves original bytes entirely – no compression, no resize, no metadata stripping

Steganography note: Better than previously thought. Pre-conditioning the cover image to match Telegram’s QF and resolution parameters could enable survival. File mode is the reliable bypass.

3. Signal – The Privacy-First Compressor

Signal takes an adaptive approach: it starts at QF 95 (relatively gentle), but if the resulting file exceeds about 420KB, it iteratively reduces quality down to a minimum of QF 50 across up to four iterations. HD mode raises the resolution limit to 4096px with less aggressive compression.

Quality factor: 95 initial, adaptive down to 50; targets ~420KB file size Resolution limit: 1600px (standard), 4096px (HD) Metadata: All stripped – Signal prioritizes privacy Key behavior: Send as document preserves original; standard mode may further reduce to 1024, 768, or 512px if needed to meet size targets

Steganography note: The high initial QF of 95 is promising, but the adaptive size-targeting means the actual output QF varies by image. HD mode at 4096px with less compression is one of the better standard-mode pipelines, though still not reliable for steganography due to pixel-domain re-encoding.

4. WhatsApp – The Jekyll and Hyde

WhatsApp presents three very different faces depending on the mode:

Standard mode is destructive. It compresses to approximately QF 50-60 (stored as a preference parameter on Android), downscales to a maximum long edge of around 1600px, converts all input formats to JPEG, strips virtually all metadata (leaving about 22 residual structural EXIF entries), and bakes EXIF orientation into pixel data. Mobile clients output progressive DCT; desktop outputs baseline with somewhat less aggressive compression.

HD mode (introduced in 2023, settable as default since 2024) is gentler: approximately QF 70-80, up to approximately 5120px maximum long edge. But it still applies recompression – it is not lossless.

Document mode bypasses everything. Byte-for-byte transfer. No compression, no resize, no metadata stripping.

Quality factor: ~50-60 (standard), ~70-80 (HD) Resolution limit: 960-1600px (standard), ~5120px (HD) Metadata: All stripped; ICC profiles discarded (causes color shift for Display P3 images) Key behavior: Custom quantization tables differ from IJG standard; mobile and desktop clients use different tables

Steganography note: Standard mode was historically completely destructive – heavy downscaling combined with aggressive recompression and custom quantization tables. However, Phasm’s Fortress sub-mode (an Armor sub-mode using BA-QIM on DC block averages) now auto-activates for short messages and survives WhatsApp standard recompression – the most aggressive default pipeline among major messengers. This is the headline capability: most DCT-domain steganographic methods fail completely on WhatsApp standard, but Fortress survives it end-to-end for short messages. HD mode is less aggressive (QF ~70-80, no resize below 5120px), so Fortress also works there. For longer messages, standard mode still destroys embedded data. “Send as document” preserves all steganographic data. For more on recompression survival, see Surviving JPEG Recompression.

5. Discord – The Moderate Middle

Discord re-encodes at QF 80 using libjpeg-turbo via their open-source Lilliput library (lilliput.JpegQuality: 80). All metadata is stripped – confirmed by forensic analysis (Nash, 2025, UC Denver). The CDN stores original files, while the media proxy serves processed versions with potential WebP/AVIF conversion.

Quality factor: 80 | Resolution limit: 10MB (free), 500MB (Nitro) | Metadata: All stripped

Steganography note: Moderate. CDN direct links may preserve originals. Nitro’s 500MB limit effectively allows uncompressed uploads.

6. Facebook Feed – The Sophisticated Processor

Facebook uses Meta’s open-source Spectrum library with MozJPEG integration. This means trellis quantization, progressive scan optimization, and custom quantization tables that differ from the standard IJG tables.

Quality factor: ~71-85 (varies by image content and dimensions) Resolution limit: 2048px longest edge; images under 100KB may avoid additional recompression Metadata: Most EXIF stripped publicly; GPS and camera info removed. Meta retains originals with full metadata internally. Key behavior: Applies unsharp mask sharpening – pre-sharpened images get double-sharpened, accentuating artifacts

Steganography note: Moderate chance of survival if the image is already 2048px or smaller (avoids downscaling), but the sharpening filter adds an additional layer of coefficient distortion beyond recompression. Custom quantization tables further complicate survival.

7. Instagram – The Image Destroyer

Instagram is one of the most destructive platforms for image fidelity. Nearly all photos are downscaled to 1080px wide (feed posts accept 320-1080px without resizing). It uses MozJPEG via Meta’s Spectrum library with adaptive, ML-driven compression – different regions of the same image may receive different effective quality levels.

The true damage comes from double compression: images are compressed on the client (via Spectrum/MozJPEG) before upload, then again on Instagram’s servers. The “upload at highest quality” toggle reduces client-side pre-compression but does not eliminate server-side re-encoding.

Quality factor: ~70-85 equivalent (IJG scale), but custom non-standard quantization tables; one test measured output equivalent to Photoshop JPEG quality 39% for a test image Resolution limit: 1080px wide (feed), 1080x1920 (stories) Metadata: All stripped (EXIF, IPTC, XMP, ICC, thumbnails) Key behavior: Double compression, AI-driven spatially-adaptive quantization, custom tables; supports Display P3 on iOS

Steganography note: Very destructive. The combination of downscaling to 1080px (destroying DCT block grid alignment), double compression, and ML-based adaptive quality makes Instagram essentially impossible for DCT-domain steganography. The Instegogram research project demonstrated limited LSB survival on Instagram using pre-sized 1080x1080 images with knowledge of Instagram’s exact quantization tables, but this approach is fragile and extremely low-capacity.

8. Snapchat – The Aggressive Compressor

Snapchat applies aggressive, network-adaptive compression (QF ~50-70), targets 1080x1920, and applies brightness adjustment. It historically used camera preview frames instead of full-resolution captures on Android. Metadata is removed and stored separately in JSON.

Steganography note: Aggressive compression, forced resizing, and brightness adjustment make Snapchat completely unsuitable.

9. TikTok – The Silent Compressor

TikTok applies QF ~70-80 compression, targets 1080x1920, and strips GPS/device metadata.

Steganography note: Forced resizing to 1080px width destroys block-aligned steganography.

10. WeChat – The Most Destructive Platform

WeChat holds the dubious distinction of being the most aggressive image processor among major platforms. Compressing from an original QF 95 to an estimated QF 53, WeChat obliterates fine detail. Max resolution appears to be around 1440px on the short side, with larger files compressed more heavily.

Quality factor: ~53-75 (most aggressive of any major platform) Resolution limit: ~1440px short side Metadata: Stripped Key behavior: May use WebP internally (16x16 block compression detected, vs. JPEG’s 8x8); content filtering applied

Steganography note: Completely destructive. QF 53 recompression obliterates virtually all DCT coefficient modifications. One academic finding of note: even at QF 95-to-53, the parity of some DCT coefficients remains unchanged – relevant for sign-based steganography research, but not for practical message embedding.

11. iMessage – The Variable Quality System

iMessage quality depends entirely on the transmission path:

Apple-to-Apple over WiFi (blue bubble): Photos sent at original quality without recompression. The original JPEG bitstream may be preserved. EXIF data is preserved between Apple devices. This is one of the best transmission methods available.

Apple-to-Apple over cellular: Carrier-dependent compression may apply.

MMS (green bubble): Heavily compressed per carrier restrictions. Output typically around 100KB, with QF of approximately 30-50 and resolution downscaled to roughly 1600x1200.

Low-Quality Image Mode: An iOS toggle that compresses all images to approximately 35-115KB.

RCS (iOS 18+): Improves cross-platform quality between iPhone and Android.

Steganography note: Apple-to-Apple iMessage over WiFi is excellent – potentially lossless. MMS is completely destructive. AirDrop remains the guaranteed-quality option for Apple device transfers.

12. Facebook Messenger

Uses the same encoder as Facebook Feed (~QF 72) but with more aggressive resolution limits: ~2048px on iOS, ~1024px on Android. HD mode (manual opt-in) goes up to 4096px. Lower resolution limits, especially on Android, make downscaling more likely.

13. Reddit

Estimated QF ~80-85 via i.redd.it hosting; 20MB max for static images. All EXIF stripped. CDN supports WebP via content negotiation. External image hosting (e.g., Imgur) bypasses Reddit’s processing entirely.

14. LinkedIn

QF ~70-85; compresses images exceeding 400x400px. Recommended feed size 1200x627. All EXIF stripped. The wide QF range and potential resizing make it unreliable for steganography.

15. LINE

Undocumented compression (photos become grainy when printed), ~1200px longest side. “Original quality” option in Settings does not fully preserve original. Unsuitable for steganography.

Platform Tiers: From Preservation to Destruction

Based on our analysis, platforms fall into four clear tiers based on how they treat your images:

Tier 1: Preserves Original (Byte-for-Byte)

These methods transmit the original file without any processing:

  • AirDrop – Apple-to-Apple; no compression, no resizing, full metadata preserved
  • Email attachments – The file is the file; no processing applied
  • USB / physical file transfer – Direct copy
  • iMessage over WiFi (Apple-to-Apple) – Original quality, EXIF preserved
  • WhatsApp “send as document” – Byte-for-byte transfer, bypasses all processing
  • Telegram “send as file” – Byte-for-byte transfer, metadata preserved
  • Signal “send as document” – Preserves original
  • phasm.link – Cloud-hosted original, decoded via WASM in the browser; bypasses all platform processing

Steganography survival: 100%. Both Ghost and Armor mode messages survive intact.

Tier 2: Probably Preserves (Mild or No Recompression)

These platforms may preserve image quality under specific conditions:

  • Twitter/X (web upload, <=5MB, <=4096px) – JPEG passthrough confirmed; metadata still stripped
  • Telegram (photo mode, <=2560px, QF ~80-82) – May pass through without re-encoding under specific conditions
  • Discord (CDN direct, Nitro) – Large file limits; CDN may store originals

Steganography survival: Likely for Armor mode; possible for Ghost mode. Depends on whether passthrough conditions are met. Pre-sizing images to fall within platform limits is critical.

Tier 3: Limited Preservation (Moderate Recompression)

These platforms recompress but may not resize, leaving some hope for robust steganography:

  • Signal HD – Starts at QF 95, may reduce; no resize below 4096px
  • WhatsApp HD – QF ~70-80; no resize below ~5120px
  • Facebook Feed – QF ~71-85; no resize below 2048px; sharpening applied
  • Discord (standard) – QF 80 re-encode
  • Reddit – QF ~80-85 re-encode

Steganography survival: Unlikely for Ghost mode; likely for Armor mode (>90% per design targets) if no resize occurs. Pre-sizing to avoid downscaling is essential.

Tier 4: Destroys (Aggressive Resize + Recompression)

These platforms resize images to smaller dimensions and apply aggressive recompression. Embedded data is destroyed:

  • Instagram – Always downscales to 1080px; double compression; ML-adaptive quality
  • WhatsApp (standard) – Downscales to ~1600px; QF ~50-60. Exception: short messages survive via Phasm’s Fortress sub-mode (BA-QIM on DC block averages), which auto-activates within Armor mode
  • WeChat – QF ~53; heavy resize; possible format conversion
  • Snapchat – QF ~50-70; forced resize; brightness adjustment
  • TikTok – Resize to 1080px; QF ~70-80
  • iMessage (MMS / green bubble) – QF ~30-50; carrier-dependent resize
  • Facebook Messenger (Android) – Resize to ~1024px
  • LINE – Resize to ~1200px; aggressive compression

Steganography survival: No (with one exception). No known DCT-domain steganography technique reliably survives these pipelines for multi-bit message embedding. The combination of resizing (which destroys 8x8 block grid alignment) and aggressive recompression is devastating. The exception: Phasm’s Fortress sub-mode uses BA-QIM on DC block averages rather than individual DCT coefficients, allowing short messages to survive even WhatsApp standard’s aggressive pipeline. Fortress auto-activates within Armor mode for short messages.

The Math Behind the Damage

To understand why some platforms preserve hidden data and others destroy it, we need to examine the mathematics of JPEG compression, recompression, and information loss.

JPEG Quality Factor and Quantization

A JPEG quality factor (QF) controls the quantization matrix used to compress DCT coefficients. The standard IJG quantization table for luminance at QF 50 defines a base matrix $B$. For other quality factors, a scaling factor $S$ is computed as:

$$S = \begin{cases} 5000 / QF & \text{if } QF < 50 \\ 200 - 2 \times QF & \text{if } QF \geq 50 \end{cases}$$

The actual quantization step for each DCT frequency position $(u, v)$ is:

$$Q(u,v) = \max\!\Bigl(1,\;\left\lfloor \frac{S \cdot B(u,v) + 50}{100} \right\rfloor\Bigr)$$

At QF 95, the scaling factor is $S = 10$, producing small quantization steps (gentle compression). At QF 50, $S = 100$ gives the base table directly. At QF 30, $S = 167$ produces large steps (aggressive compression). The relationship is non-linear: the quality drop from QF 95 to QF 85 is perceptually much smaller than from QF 55 to QF 45.

Information Loss During Recompression

When a JPEG is recompressed, each quantized DCT coefficient $c$ passes through a dequantize-requantize cycle. If the original quantization step is $q_1$ and the new step is $q_2$, the recompressed coefficient $c'$ is:

$$c' = \left\lfloor \frac{\left\lfloor c \cdot q_1 + 0.5 \right\rfloor}{q_2} + 0.5 \right\rfloor$$

When $q_2 > q_1$ (recompression at lower quality), information is destroyed because $q_2$ divides a wider range of values into fewer bins. Concretely, if a coefficient is embedded with a perturbation of $\pm 1$ quantization step (as in QIM-based steganography), that perturbation survives only if it shifts the coefficient into a different bin under the new quantization step.

The survival probability for a coefficient modified by $\pm 1$ under requantization is approximately:

$$P_{\text{survive}} \approx \frac{q_1}{q_2} \quad \text{for } q_2 > q_1$$

When $q_2 = q_1$ (same QF), most coefficients survive. When $q_2 = 2 \cdot q_1$ (roughly QF 85 to QF 65), about half the modifications are lost.

Expected Bit Error Rate at Various Quality Drops

The real-world picture is more complex than the single-coefficient model above because platforms perform full pixel-domain re-encoding (not just coefficient-domain requantization). The pixel rounding step introduces additional errors. Measured bit error rates (BER) from the academic literature for STDM embedding (the technique used by Phasm’s Armor mode) at an original QF of 85:

Recompression QF Coefficient-Domain Only Full Pixel Re-encode With Reed-Solomon ECC
85 (same) < 0.5% 1-3% ~0%
75 (mild drop) 1-5% 3-8% < 1%
65 (moderate drop) 5-12% 8-15% 2-5%
50 (aggressive) 10-20% 15-25% 5-12%
30 (very aggressive) 25-40% 30-45% 15-30%

The “With Reed-Solomon ECC” column shows the power of error correction: at mild quality drops, ECC reduces the effective error rate to near zero. But against aggressive compression (QF 50 and below), even strong ECC cannot fully compensate.

For Ghost mode (stealth embedding), which uses J-UNIWARD minimal-distortion embedding rather than robust quantization, the BER is significantly worse – even mild recompression can destroy the signal. Ghost mode is designed for scenarios where the image will not be re-encoded.

Why Downscaling Is Worse Than Recompression

The numbers above assume the image is not resized. Downscaling is categorically worse.

JPEG steganography operates on 8x8 pixel blocks. When an image is resized, the pixel grid shifts: block (3, 7) in the original may span parts of four different blocks in the resized image. For a resize by factor $r$, the block grid alignment error is:

$$\Delta = 8 - (8r \bmod 8)$$

For non-integer scale factors (which all social media downscaling uses), $\Delta$ is effectively random. The BER approaches 50% – equivalent to guessing.

This is not a matter of degree. A 4000x3000 image downscaled to 1080px by Instagram has its 187,500 DCT blocks remapped to roughly 13,500 blocks with completely misaligned boundaries. While recompression degrades steganographic data gradually, downscaling obliterates it.

What This Means for Steganography

Measured Survival Against Real Platforms

Academic studies have tested steganographic methods against real platforms:

Method Twitter/X Facebook Telegram Signal WhatsApp (std) Instagram WeChat
Sign-based (MSDC) < 5% BER < 5% BER Good Unknown Fail Fail Fail
TCM + ECC < 2% BER < 3% BER Excellent Unknown Fail Fail Fail
STDM (Phasm Armor) Likely* Likely* Moderate Possible* Fail Fail Fail
BA-QIM (Phasm Fortress) Likely* Likely* Likely Possible* Short msgs Fail Fail
Deep learning (StegaStamp) ~92% acc ~90% acc Excellent Good ~70% acc ~60% acc Fail

* Only if image is already at or below the platform’s resolution limit (no downscaling occurs). Design target for Twitter/Facebook (no resize): >90% survival.

The pattern: no traditional DCT-domain steganography reliably survives platforms that resize (Instagram, WhatsApp standard, WeChat, Snapchat). Twitter/X and Facebook are the most promising social platforms if pre-sized. Telegram’s passthrough at 2560px or below is uniquely viable among messengers. Deep learning methods show better robustness but carry only 48-100 bits – far below the kilobyte-level payloads needed for text messages. The “send as file” bypass remains the most reliable path.

The Fortress exception: Phasm’s Fortress sub-mode breaks through the resize barrier for short messages. By embedding into DC block averages using BA-QIM with Watson perceptual masking rather than individual DCT coefficients, Fortress operates on a signal that partially survives downscaling and aggressive recompression. This enables short message survival on WhatsApp standard – previously considered impossible for DCT-domain steganography. Fortress auto-activates within Armor mode when the message is short enough.

The Survival Hierarchy

Twitter/X > Facebook > Telegram (photo) > Signal (HD) > Discord > Reddit > Signal (std) > WhatsApp (HD) >> WhatsApp (std, Fortress*) > Snapchat > TikTok > Instagram > WeChat

The “>>” represents a categorical gap: everything left might survive with robust embedding and ECC. Everything right involves forced resizing that makes survival impossible for standard Armor mode. *WhatsApp standard now supports short messages via Phasm’s Fortress sub-mode, which uses BA-QIM on DC block averages to survive aggressive recompression and downscaling.

The Decision Flowchart

Use this flowchart to determine whether you can send a hidden message via a given platform:

                flowchart TD
                    A["I want to send a hidden message
via Platform X"] --> B{"Does Platform X
have 'Send as File'
or document mode?"}
                    B -->|"Yes
(WhatsApp, Telegram, Signal)"| C["Use 'Send as File' mode
✅ Message survives intact"]
                    B -->|No| D{"Is Platform X
in Tier 1?
(AirDrop, Email, USB, iMessage WiFi)"}
                    D -->|Yes| E["Send directly
✅ Message survives intact"]
                    D -->|No| F{"Does Platform X
resize your image?"}
                    F -->|"Yes
(Instagram, Snapchat,
WeChat, TikTok)"| G["❌ Message will be destroyed
Use phasm.link instead"]
                    F -->|"Yes, but WhatsApp std"| M{"Is your message
short enough for
Fortress sub-mode?"}
                    M -->|Yes| N["✅ Fortress auto-activates
(BA-QIM on DC block averages)
Short messages survive"]
                    M -->|No| G
                    F -->|"No / only if above limit"| H{"Is your image already
below the platform's
resolution limit?"}
                    H -->|No| I["Resize BEFORE embedding
to platform's max resolution"]
                    I --> J{"Did you use
Armor mode?"}
                    H -->|Yes| J
                    J -->|Yes| K["⚠️ Possible survival
Depends on QF drop and ECC"]
                    J -->|"No (Ghost mode)"| L["❌ Ghost mode unlikely
to survive recompression.
Use phasm.link instead"]

                    style C fill:#4CAF50,color:#fff
                    style E fill:#4CAF50,color:#fff
                    style G fill:#f44336,color:#fff
                    style N fill:#4CAF50,color:#fff
                    style K fill:#FF9800,color:#fff
                    style L fill:#f44336,color:#fff

The simplest path is always at the top: use “send as file” or a Tier 1 method. For platforms that recompress but do not resize, Armor mode with pre-sizing offers conditional survival. For WhatsApp standard, the Fortress sub-mode now enables short message survival despite aggressive recompression and downscaling. For other platforms that resize, use phasm.link to share via a cloud-hosted link decoded in the browser via WebAssembly.

The “Send as File” Workaround

Several messaging platforms offer a mode that completely bypasses image processing. This is the single most important piece of practical advice in this article:

Platform How to Bypass What Happens
WhatsApp Tap the attachment icon, choose “Document” instead of “Camera” or “Gallery” Byte-for-byte transfer. Zero processing.
Telegram Long-press the send button, choose “Send as File” (or use the paperclip > File) Byte-for-byte transfer. Metadata preserved.
Signal Use the attachment icon and choose the file/document option Original preserved.
Discord (Nitro) Upload as file (500MB limit) CDN stores the original.

When you send a photo “as a file,” the app treats it as an arbitrary binary blob – no JPEG decoding, no resizing, no recompression, no metadata stripping. The file arrives identical to what you sent.

The trade-off: The recipient sees a file attachment, not a photo preview. They must download and open it. For steganography, this is acceptable – the image looks ordinary once opened. For casual photo sharing, it is less convenient but preserves full quality.

Phasm offers an alternative that works across all platforms: phasm.link. Upload a stego image to phasm.link and share the resulting URL. The recipient opens the link in any browser and decodes client-side via WebAssembly – no app install required (iOS users get an instant App Clip experience).

Because the link points to the original JPEG, no platform processing occurs. Share the link via Instagram DMs, WeChat, Snapchat, or any other platform – the platform sees a URL, not an image to process.

Practical Recommendations

For Photographers: Preserving Image Quality

  1. Use “send as file/document” on messaging apps whenever possible. The quality difference is dramatic – your 8-megapixel, QF-95 original versus a 1.5-megapixel, QF-55 compressed version.

  2. Pre-size images for social media. If you are posting to Instagram, resize to exactly 1080px wide before uploading. If posting to Facebook, resize to 2048px. This prevents the platform from applying its own (often poor) downscaling algorithm.

  3. Avoid double-platform hops. Downloading a photo from WhatsApp and re-uploading to Instagram means double compression. Always go back to the original when possible.

  4. Be aware of metadata stripping. Every platform except iMessage (Apple-to-Apple) and “send as file” modes strips EXIF data including GPS location, camera model, date taken, and copyright information. If you need metadata preserved, use email attachments or AirDrop.

  5. For critical work, use direct transfer methods. AirDrop, email attachments, USB transfer, or cloud storage links (Google Drive, Dropbox) preserve original quality. No social media or messaging platform matches this.

For Privacy Researchers: Understanding Metadata Behavior

  1. Metadata stripping is nearly universal. All 15 platforms strip EXIF data in their standard photo-sharing modes. Only AirDrop, email, and “send as file” modes preserve metadata.

  2. Platforms retain your metadata internally. Facebook, Instagram, and others strip metadata from the publicly served image but keep the original (with full metadata) on their servers.

  3. ICC profiles are silently dropped. Most platforms strip ICC color profiles without converting pixel values, causing images shot in Display P3 or Adobe RGB to appear with slightly shifted colors.

  4. WhatsApp bakes orientation into pixels. Instead of relying on the EXIF orientation tag, WhatsApp physically rotates/flips the pixel data – good for compatibility, but another processing step.

For Steganography Practitioners: Maximizing Survival

  1. Tier 1 methods always work. AirDrop, email, USB, phasm.link – use these when you control the transmission method.

  2. “Send as file” is your best friend. On WhatsApp, Telegram, and Signal, this completely bypasses image processing.

  3. Pre-size images to platform limits before embedding. If you must send as a photo (not a file) through Telegram, ensure your image is 2560px or below. For Twitter, stay at 4096px or below and under 5MB. For Facebook, stay at 2048px or below. Pre-sizing eliminates the catastrophic downscaling step.

  4. Use Armor mode, not Ghost mode, for any channel that recompresses. Ghost mode’s J-UNIWARD-based minimal-distortion embedding is designed for stealth, not robustness. Armor mode’s STDM embedding with error correction is specifically designed to survive recompression.

  5. Accept that some platforms are off-limits – with one exception. Instagram, WeChat, Snapchat, and TikTok will destroy your embedded message. WhatsApp standard now supports short messages via Phasm’s Fortress sub-mode (auto-activating within Armor mode). For everything else, use phasm.link or “send as file.” For tips on keeping Phasm discreet on your device, see How to Hide Phasm on Your Phone.

  6. For Twitter/X: aim for passthrough. Ensure your image is already JPEG, 4096px or smaller, and under 5MB. Upload via the web client. Under these conditions, Twitter preserves the original quality.

  7. For Telegram: match the expected QF. Research suggests Telegram may pass through images already encoded at approximately QF 80-82. Pre-encoding your cover image at this quality before embedding may improve survival.

Conclusion

The landscape of platform image processing ranges from AirDrop (preserves every byte) to WeChat (QF 53 compression that obliterates detail). For most users, the practical takeaway is simple: if image quality matters, send your photos as files, not as photos. The “send as document” feature on WhatsApp, Telegram, and Signal is the single most impactful thing you can do to preserve quality, and almost nobody uses it.

For steganography, the takeaway is that platform processing divides the world into two categories: platforms you can work with (no resize, moderate recompression) and platforms you cannot (forced resize or aggressive compression). The new Fortress sub-mode within Armor blurs this line – by embedding into DC block averages via BA-QIM, Fortress enables short message survival even on WhatsApp standard. Understanding this division – and having tools like Phasm and phasm.link that work around it – is essential for reliable steganographic communication. For related reading, see Surviving JPEG Recompression, UERD vs J-UNIWARD Detection Benchmarks, and How to Hide Phasm on Your Phone.

This data reflects the state of these platforms as of February 2026. Processing pipelines change without announcement. We will update this analysis as new information becomes available.

Frequently Asked Questions

Does steganography work on WhatsApp?

It depends on the mode and message length. WhatsApp’s standard mode aggressively compresses and downscales photos, which destroys most steganographic data. However, Phasm’s Fortress sub-mode (which auto-activates for short messages within Armor mode) survives WhatsApp standard recompression by embedding into DC block averages rather than individual DCT coefficients. For longer messages or maximum reliability, sending the image “as a document” through WhatsApp preserves the original file byte-for-byte with zero processing.

Which messaging apps preserve hidden messages?

Methods that always preserve steganographic data include AirDrop, email attachments, iMessage over WiFi (Apple-to-Apple), and the “send as file/document” mode on WhatsApp, Telegram, and Signal. Twitter/X can also preserve original JPEG quality for web uploads under 5 MB and 4096 pixels. Telegram may pass through images under 2560 pixels without re-encoding under certain conditions. For guaranteed delivery across any platform, sharing a phasm.link URL bypasses all image processing entirely.

Does Instagram destroy steganographic data?

Yes. Instagram is one of the most destructive platforms for steganography. It downscales nearly all photos to 1080 pixels wide, applies double compression (client-side and server-side), and uses ML-driven spatially-adaptive quantization with custom non-standard quantization tables. The combination of forced resizing (which destroys 8x8 DCT block alignment) and aggressive recompression makes Instagram incompatible with any known DCT-domain steganographic method for practical message embedding.

How can I send steganographic images through social media?

The most reliable approach is to avoid the platform’s image processing entirely. Use “send as file” or “send as document” modes on WhatsApp, Telegram, or Signal – these transmit the file byte-for-byte with no compression or resizing. Alternatively, upload the stego image to phasm.link and share the resulting URL through any platform; the recipient decodes in their browser via WebAssembly. If you must send as a photo, pre-size your image to stay within the platform’s resolution limit (e.g., 4096px for Twitter, 2560px for Telegram, 2048px for Facebook) and use Armor mode for recompression resilience.

References

Platform-Specific Technical Analysis

  1. Instagram Engineering, “Bringing Wide Color to Instagram,” 2017. engineering.instagram.com

  2. Citizen Lab, “Can’t Picture This: An Analysis of Image Filtering on WeChat Moments,” August 2018. citizenlab.ca

  3. Meta Engineering, “Spectrum: A Client-Side Image Processing Library,” Meta Open Source, 2019.

  4. TechCrunch, “Twitter Will Now Preserve JPEG Quality for Photo Uploads on Web,” December 2019.

  5. Compress-or-Die, “Better Image Quality in Your Twitter Tweets.” compress-or-die.com

  6. M. Risemberg, “WhatsApp File Structure Analysis,” UC Denver Thesis, 2020.

  7. D-T. Dang-Nguyen et al., “How Social Media Platforms Handle Uploaded Images,” arXiv preprint, arXiv:2302.12133, 2023.

  8. R. Fahmi, “Telegram-Like Image Optimization on Android.” rifqimfahmi.dev

  9. Discord Engineering, “How Discord Resizes 150 Million Images Every Day with Go and C,” Discord Blog. Discord, “Lilliput: A Go Library for Image Resizing,” GitHub.

  10. A. Nash, “Forensic Analysis of Discord Image Processing,” UC Denver Thesis, 2025.

  11. Signal Android Compression Source, GitHub.

  12. Photo Taco Podcast, “Dimensions and Quality for Social Media Photo Sharing.”

  13. J. Wright, “How to Upload Photos to Instagram with the Highest Possible Quality.” joshwright.com

  14. Luban, “WeChat-Like Image Compression,” GitHub.

  15. EXIFData.org, “Do Social Media Sites Strip EXIF Data? 2025 Test,” 2025.

Academic Steganography Research

  1. J. Zhu et al., “HiDDeN: Hiding Data With Deep Networks,” European Conference on Computer Vision (ECCV), 2018.

  2. M. Tancik et al., “StegaStamp: Invisible Hyperlinks in Physical Photographs,” IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2019.

  3. “Using Telegram as Carrier for Image Steganography,” ACM ARES Conference, 2022.

  4. J. Butora and J. Fridrich, “Errorless Robust JPEG Steganography Using Outputs of JPEG Coders,” arXiv preprint, arXiv:2211.04750, 2023.

  5. T. Qiao et al., “Robust Steganography in Practical Communication: A Comparative Study,” EURASIP Journal on Image and Video Processing, 2023.

  6. Y. Zhang et al., “Robust JPEG Steganography Based on the Robustness Classifier,” EURASIP Journal on Information Security, 2023.

  7. J. Butora et al., “Errorless Robust JPEG Steganography Using Steganographic Polar Codes,” EURASIP Journal on Information Security, 2024.

  8. “Robust Image Steganography Against JPEG Compression Based on DCT Residual Modulation,” Signal Processing, 2024.

  9. “A Matching Robust Adaptive Steganography Scheme for JPEG Images over Social Networking Platforms,” Signal Processing, 2025.