The expensive mistake: accusing without evidence
If you just discovered the leak, start with what to do in the first hour when your content leaks for preservation and branching steps before you narrow in on verification here.
Creators under stress want a name immediately. Public call-outs feel decisive, but without a recovered subscriber ID or solid delivery proof, you risk accusing the wrong person and training your audience that your enforcement is guesswork.
Verification is not about delaying justice. It is about preserving the evidence chain so Inspect, metadata review, and your delivery log can actually answer the question.
Step 1: Save the file exactly as downloaded
Do not screenshot the post if you can download the image. Screenshots create a new bitmap that may destroy invisible marks and strip useful metadata.
Save:
- the downloaded file itself
- the URL or channel name
- the date you found it
- a one-line note of what you saw
If you need a structured list, generate the leak response playbook for your scenario.
Step 2: Compare against your original
You need a reference copy: export master, last delivery batch, or the nearest file you still control. Use the leak similarity checker to see whether the suspect file is visually the same image after resize or mild re-compression.
Interpret the result honestly:
| Result | What it usually means |
|---|---|
| Likely same | Same image, possibly resized or re-saved |
| Possibly edited | Crop, overlay, color shift, or heavier compression |
| Probably different | Unrelated file, screenshot, or heavily altered repost |
Visual match helps you decide whether Inspect is worth running. It does not identify which subscriber leaked.
Step 3: Audit metadata on the suspect copy
Some leaks still carry EXIF, IPTC, or rights fields that narrow timing or workflow. Run the suspect file through the EXIF viewer before you edit or re-export it.
Metadata is inconsistent on social platforms, but when it survives, it can corroborate your timeline.
Step 4: Recover the subscriber ID in Inspect
If you delivered with invisible per-subscriber IDs, drop the leaked file into Foddo Inspect on your Windows machine. When the mark survived the route it took, you get the recipient ID, timestamp, and payload fields to match against your CSV or delivery log.
For token-based methods such as TrustMark, WAM, and Robust Transform, full recovery also depends on the local payload mapping Foddo stores when the files were generated. Without that mapping from the same install, you may recover a token but not the subscriber details behind it.
No recovered ID usually means the mark did not survive. That does not mean Inspect failed. Review the survival simulator for your delivery channel if you are unsure why.
Step 5: Act privately with matched proof
Cross-check the recovered ID to one subscriber account. Handle access revocation, refunds, and platform reports through private channels first. Document what you matched and when.
What this workflow does not promise
- Similarity alone is not proof of which subscriber leaked
- Screenshots and aggressive social compression often destroy invisible marks
- Token-based methods need the local payload mapping from the Foddo install that generated the files
- This guide is operational workflow, not legal advice
Tools in this path
- Leak response playbook: personalized first-hour steps
- Leak similarity checker: original vs suspect comparison
- EXIF viewer: metadata audit on the suspect copy
- Foddo Inspect: recover invisible recipient IDs when marks survive
For the full invisible watermarking story, read how invisible watermarking traces leaks.