Skip to content
HostProof

▸ Field notes · damage claims that survive denial

Filed 09 MAY 2026 Draft A
Go back
Evidence · Exhibit

Why WhatsApp Strips EXIF Data (and Kills Your AirCover Claims)

The fastest way to invalidate a damage photo is to send it through WhatsApp. EXIF gets stripped, timestamps vanish, file integrity flags trip. Here is exactly what happens and how to avoid it.

6 MIN READ

If your cleaner shoots damage photos on their phone and WhatsApps them to you, and you then submit those photos to AirCover — your claim is already compromised before a specialist ever opens the thread. The reason is technical, specific, and fixable: WhatsApp and similar messaging apps strip EXIF metadata and re-compress images by default, which removes the capture timestamp, the geolocation, and the file integrity fingerprint that AirCover specialists use to evaluate credibility.

This is one of the most common invisible killers of AirCover claims. Hosts submit photos they believe are clean evidence, and the specialist sees “re-saved file, stripped metadata, timestamp unclear.” The claim goes into the weak-evidence bucket without anyone realising why.

What EXIF actually is

EXIF (Exchangeable Image File Format) is metadata embedded inside every JPEG/HEIC file your phone camera produces. It typically contains:

  • Capture timestamp (date, time, timezone if the phone has it)
  • Camera model and lens
  • Geolocation (GPS coordinates if enabled)
  • Orientation, flash, ISO, aperture settings
  • A unique camera serial number in some cases

For AirCover purposes, the critical field is the capture timestamp. It proves when the photo was actually taken, independent of your word. Without it, the specialist has only the upload timestamp, which proves nothing about capture.

What WhatsApp does to your photos

When you send a photo through WhatsApp, three things happen in sequence:

  1. Compression. The app reduces file size by ~70% to save bandwidth. This re-encodes the JPEG with different quality settings than the original.
  2. Metadata stripping. EXIF data is removed — capture timestamp, geolocation, camera model, everything. WhatsApp does this both for privacy reasons and to reduce file size further.
  3. Re-save. The file written to the recipient’s device has a new file creation timestamp (when WhatsApp saved it), not the original capture time.

The file that lands in your inbox is technically the same image — visually. But forensically, it is a completely different artefact: re-compressed, stripped of origin metadata, with a new timestamp. It has no provable link back to the moment the original photo was taken.

The "re-saved file" flag

AirCover specialists can detect re-saved JPEGs. The compression fingerprint is visible. When they see a re-saved file claiming to be original evidence, the default evaluation is skeptical, regardless of what the photo actually shows.

The apps that do the same thing

WhatsApp is the most famous offender, but most messaging apps do the same:

  • WhatsApp — strips EXIF, re-compresses, always.
  • Facebook Messenger — strips EXIF, re-compresses unless you use “send as uncompressed file” mode.
  • Instagram DM — strips EXIF, re-compresses heavily.
  • Telegram — strips EXIF by default, preserves it only if you send as “file” not as “photo.”
  • iMessage — preserves EXIF for photos sent as-is within Apple ecosystem, strips when crossing to SMS or non-Apple.
  • Signal — strips EXIF by design (privacy feature), re-compresses.
  • Email — preserves EXIF usually, though some webmail clients (Gmail web with photo attachment) sometimes strip.
  • Slack, Discord — preserves EXIF generally, depends on upload flow.

Any messaging app routed through a cleaner → host → AirCover chain is a metadata destruction pipeline. The photo loses provenance at step one.

The “send as file” loophole

Most messaging apps have an option to send an image as a file rather than as a photo attachment. This preserves metadata in most cases:

  • Telegram: paperclip → “File” → select the image. EXIF preserved.
  • WhatsApp: paperclip → “Document” → select the image. EXIF preserved.
  • Signal: does not have this loophole — all images get stripped.

This works, but relies on cleaners remembering to tap the right menu option every time. In practice, most cleaners will default to normal send and forget. A single wrong tap destroys the evidence.

The cloud-sync trap

Another invisible stripper: cloud photo services with “optimised” sync.

  • iCloud Photos with “Optimize iPhone Storage” — the full-resolution original lives in iCloud, but the version on your phone is a compressed thumbnail. When you export or share, you may get the compressed version without realising.
  • Google Photos “High quality” (now “Storage saver”) — re-compresses images upon upload, strips some EXIF fields.
  • Dropbox camera upload — preserves original usually, but check your account settings.
  • OneDrive photo sync — preserves originals.

If your workflow goes phone camera → cloud sync → download → submit, audit whether the download is the original or a compressed copy. In many default configurations, you are getting the compressed copy.

The correct workflow for AirCover-grade photos

Three options, in order of convenience:

Option 1 — Direct capture, direct upload. Shoot the photo, upload it directly to the claim interface without sending it through any app or syncing. Preserves everything.

Option 2 — “Send as file” discipline. If photos must travel through a messaging app, enforce the “send as file” habit with everyone on your team. Train once, test twice.

Option 3 — Dedicated capture-to-storage pipeline. Use an app or tool that captures photos with EXIF preservation guaranteed. The HostProof app is built for this — photos captured in-app keep EXIF intact, get SHA256-hashed on capture, and upload directly to the claim-ready storage.

Option 3 is the only option that fails gracefully when cleaners forget the menu-tap. It is the reason the discipline gets automated.

How to verify a photo has EXIF intact

Quick test, before you submit any claim evidence:

macOS: right-click photo → Get Info → “More Info” shows EXIF fields if present.

Windows: right-click → Properties → Details tab shows capture timestamp.

Any platform (web): upload the photo to exifcheck.online or similar — shows all EXIF fields. If capture timestamp is missing, the photo has been stripped.

The 60-second pre-submit EXIF check

Before submitting any photo to AirCover, spot-check one or two via the Properties/Get Info panel. If capture timestamp is there, you are fine. If it is blank, the photo passed through something that stripped it — find the original.

What to do if you already WhatsApp-ed a photo you need

Three recovery paths, in order of strength:

  1. Get the original from source. The cleaner’s phone probably still has the uncompressed original. Ask them to airdrop, email as attachment, or upload directly. The compressed version in your chat is a copy; the original exists.
  2. Cross-reference with other evidence. If the photo metadata is gone, back up the claim with the cleaner’s dated statement, your Resolution Center message timestamp, and any other bracketing evidence that establishes timing.
  3. Acknowledge and pivot. If the original is truly lost, file the claim with what you have and anchor the narrative on the parts that are still strong. Do not hide the metadata gap — specialists spot it anyway.

Bottom line

WhatsApp and similar apps are the silent killer of AirCover claims because they strip metadata invisibly. The photo looks fine, the host thinks the evidence is strong, the specialist sees a re-saved file with no provenance. Fix the workflow: direct capture to upload, or “send as file” everywhere, or a dedicated capture-to-storage pipeline. Verify EXIF before submission. The specific technical detail saves real money on real claims.

For the full photo documentation approach that handles EXIF preservation automatically, use the HostProof app or the photo inspection checklist for the manual workflow.


Sources & further reading

Last updated: 2026-04-22. Messaging-app EXIF handling reflects default behaviour as of late 2025; individual app settings and versions may differ.

▸ Related filings · Same cluster