How to reveal hidden pre-edit previews in profile and social photos
- Step 1Confirm you are on a Developer (or higher) plan — This is a Developer-tier tool. On Free, Pro, or Pro + Media the page shows a plan overlay and the dropzone is disabled. Developer raises the per-file limit to 2 GB, far above any profile photo.
- Step 2Get the original file, not a screenshot — A screenshot or a photo pulled from a social feed is re-encoded and almost never keeps the camera's original preview. You need the actual file someone sent you — an AirDrop, an email attachment, a 'send as file' chat image. Drop that file; the dropzone accepts any type (
*/*) and processes one file at a time. - Step 3Let the byte-carver scan — The tool reads the file into a buffer and walks it from offset 1 for a
FF D8 FFStart-of-Image that is not the host header at offset 0, then searches forward up to 200,000 bytes for the closingFF D9. There are no options, presets, or controls. - Step 4Read the result — If a qualifying embedded JPEG (1 KB-200 KB) is found, the panel shows
bloband a Download button. If none qualify, it showsNo embedded thumbnails detected in this file.— which is the common case for anything that passed through a social platform's re-encoder. - Step 5Download and compare side by side — Click Download to save
<sourcename>-thumbnails.zip. Inside, each preview isthumb-0.jpg,thumb-1.jpg, … in byte order. Open each one next to the posted photo and look for un-smoothed skin, a different face shape, or a different colour grade in the preview. - Step 6Treat a clean result as inconclusive — No leaked preview does not mean the photo is unedited — it usually just means the platform re-encoded it. This tool reveals a leak when one exists; it cannot certify authenticity. For broader file-signature context, you can pair it with magic-byte-validator.
When a profile photo will and won't yield a pre-filter preview
A leak survives only on the original file from an editor that didn't regenerate the preview. Social platforms re-encode aggressively, so most shared photos yield nothing.
| How you got the photo | Likely embedded preview state | Useful here? |
|---|---|---|
| Original file, edited app left the preview | Un-filtered camera preview intact | Yes — the strongest case |
| Original file, app regenerated the preview | Preview matches the filtered image | No earlier state — inconclusive |
| Downloaded from a social feed | Preview rebuilt by the platform's CDN | Rarely useful |
| Screenshot of the photo | No camera preview at all | No — nothing to carve |
| Sent 'as a file' over chat / email | Often keeps the original preview | Yes — best file to ask for |
The byte rules the carver applies
Fixed values from the implementation. There are no user-adjustable options.
| Rule | Value | Why it matters for a profile photo |
|---|---|---|
| Start marker | FF D8 FF after offset 0 | Finds the embedded preview while skipping the photo's own header |
| End marker, window | FF D9 within 200,000 bytes | Closes the carved preview; a preview with no nearby EOI is abandoned |
| Minimum kept size | greater than 1,024 bytes | A real camera preview is above this; sub-1 KB runs are dropped as noise |
| Maximum kept size | less than 200,000 bytes | Keeps the small preview; a full-size embedded copy over 200 KB is skipped |
| Max thumbnails per file | 16 | Up to 16 carved previews; a 17th is not extracted |
| Output | ZIP of thumb-N.jpg | Every carved stream is JPEG, named <sourcename>-thumbnails.zip |
Plan, input, and output behaviour
Operational facts for checking a profile or social photo with the hidden-thumbnail-extractor.
| Aspect | Behaviour | Note |
|---|---|---|
| Minimum plan | Developer | Free / Pro / Pro + Media show a plan overlay |
| Per-file size limit | 2 GB on Developer; unlimited on Enterprise | Far above any profile photo |
| Files per run | 1 | No batch — check each photo individually |
| Accepted types | Any (*/*) | Attachments, AirDrops, and saved chat files all work |
| Output (none found) | Plain text message | No embedded thumbnails detected in this file. |
| Where it runs | Browser only | The photo's bytes never leave your device and are not retained |
Cookbook
Byte-level walkthroughs of how the carver behaves on real profile and social photos. The Input / Result blocks describe markers and sizes, not literal binary.
Beauty-filtered selfie with the raw capture in the preview
A selfie was skin-smoothed and jaw-slimmed in an editor that rewrote the main image but left the camera's EXIF preview intact.
Input: selfie.jpg (host SOI at offset 0)
... main image (smoothed, retouched) ...
APP1/EXIF IFD1 -> preview (un-smoothed capture, 21 KB)
Scan: SOI at offset > 0, EOI within 200 KB,
size 21 KB -> KEEP
Result: selfie-thumbnails.zip
thumb-0.jpg (the un-filtered original)
findings.count = 1Photo from a social feed -- platform re-encoded it
An image saved from a social app was re-encoded server-side; the embedded preview matches the posted version, so no earlier state survives.
Input: from-feed.jpg SOI (offset 0) posted image ... CDN-rebuilt preview -> matches the post, 13 KB Scan: a preview exists but matches the published image Result: from-feed-thumbnails.zip thumb-0.jpg (matches the post -> inconclusive)
Screenshot -- nothing to carve
You screenshotted the photo instead of saving the original file. A screenshot has no camera preview embedded.
Input: screenshot.png SOI (offset 0) screenshot pixels ... (no secondary FF D8 FF ... FF D9 in window) Scan: no qualifying embedded JPEG Result (text, not a download): No embedded thumbnails detected in this file.
Multi-frame share yields several previews
A photo re-saved through two apps accumulated more than one embedded JPEG. The carver pulls each in-bounds preview.
Input: re-saved.jpg SOI (offset 0) main image (large) ... preview A (from app 1) -> 18 KB -> KEEP preview B (from app 2) -> 24 KB -> KEEP Scan: primary at offset 0 skipped; A and B in bounds Result: re-saved-thumbnails.zip thumb-0.jpg (preview A) thumb-1.jpg (preview B) findings.count = 2
Ask for the right file, then check the signature
Workflow: request the original 'as a file', carve the preview, and confirm the file's true type before drawing a conclusion.
Step 1 -- get the original file (not a screenshot): ask for the photo sent 'as a file' Step 2 -- carve the preview (this tool): drop profile.jpg get thumb-0.jpg in profile-thumbnails.zip Step 3 -- confirm it is really a JPEG: open /security-tools/magic-byte-validator drop profile.jpg -> confirm declared vs actual type Result: an un-filtered preview + a verified file type.
Edge cases and what actually happens
Photo passed through a social platform's re-encoder
InconclusiveSocial apps re-encode uploads server-side and rebuild the embedded preview, so an image saved from a feed almost never yields the camera's original. A matching or absent preview here is not evidence the photo is unedited — it usually just means the platform processed it.
You used a screenshot instead of the original
Weak inputA screenshot is a fresh capture with no embedded camera preview, so the carver will typically find nothing. To get a meaningful result you need the original file the person sent — ideally shared 'as a file' so the platform does not strip its metadata.
No qualifying embedded JPEG in the file
By designWhen no secondary FF D8 FF ... FF D9 stream falls within the 1 KB-200 KB window, the result is the text No embedded thumbnails detected in this file. with nothing to download. This is the common outcome and does not by itself prove the photo is real or fake.
It is not a face-swap or deepfake detector
Out of scopeThis carver only recovers a separate embedded preview. It cannot detect a face swap, a generated image, or an AI edit on the main photo. A clean result says nothing about whether the image is synthetic; for that you need a dedicated analysis, not a byte-carver.
Preview stored as PNG, GIF, or BMP
Not detectedThe carver recognizes only the JPEG marker FF D8 FF. A preview in PNG, GIF, or BMP is not found. To inspect what the file actually contains at the signature level, use hex-header-inspector or magic-byte-validator.
Embedded JPEG larger than ~200 KB
By designAn embedded JPEG of 200,000 bytes or more is skipped, because the upper bound restricts output to thumbnail-scale previews. A full-resolution embedded copy is not extracted; inspect the raw bytes with hex-header-inspector if you suspect one.
Embedded JPEG smaller than 1 KB
By designCarved streams of 1,024 bytes or fewer are rejected as likely-coincidental byte patterns. A genuine but unusually small preview just under 1 KB would also be dropped.
Missing or far-away End-of-Image marker
SkippedAfter a start marker the carver searches forward at most 200,000 bytes for the closing FF D9. A corrupt preview with no EOI in that window is abandoned, so a damaged-but-real preview may not be recovered.
More than 16 previews in one file
TruncatedThe result is capped at the first 16 carved JPEGs in byte order. A photo re-saved through many apps could exceed this; a count of 16 should be read as 'at least 16'.
The file you received stays unchanged
PreservedExtraction is read-only — the tool reads the bytes through the browser and never writes back, so the file you were sent stays bit-identical. You can confirm with multi-hash-fingerprinter by comparing the hash before and after.
Frequently asked questions
Can this tell me if a dating-profile photo is fake?
Not on its own. It can reveal an un-filtered original when the editor left the embedded preview behind, which is useful evidence of retouching. But it is not a deepfake or face-swap detector, and most photos shared through social apps are re-encoded and carry no recoverable preview — so a clean result is inconclusive.
Why would the un-filtered face still be in the file?
Cameras embed a small JPEG preview for fast gallery rendering. When a beauty or retouch app rewrites the main image but doesn't regenerate that preview, the file keeps a tiny copy of the un-filtered capture.
Will it work on a photo I saved from someone's profile?
Usually not. Social platforms re-encode uploads and rebuild the preview, so a saved feed image rarely keeps the camera's original. Ask for the photo sent 'as a file' over chat or email for the best chance of a recoverable preview.
Does a screenshot work?
No. A screenshot is a fresh capture with no embedded camera preview, so the carver will typically find nothing. You need the original file, not a screenshot of it.
Does checking the photo modify it?
No — extraction is read-only. The tool reads the bytes via the browser and never writes back, so the file you received stays bit-identical. You can confirm with multi-hash-fingerprinter.
What does 'No embedded thumbnails detected' mean?
No JPEG preview between 1 KB and 200 KB was found after the host header. It commonly means the photo was re-encoded by a platform or its preview was stripped — it is not proof the photo is unedited.
What format are the extracted previews?
Always JPEG. Each carved stream is a JPEG, so the files in the ZIP are named thumb-0.jpg, thumb-1.jpg, and so on, regardless of the source file type.
Can I check several profile photos at once?
No. The tool runs on one file per pass and names the output ZIP after that single file. Check each photo individually.
Do I need to set any options?
No. There are no controls, presets, or format pickers — you drop one file and the carver runs with fixed rules. Only embedded JPEG previews between 1 KB and 200 KB are extracted.
What plan do I need and how large can the file be?
It is a Developer-tier tool. Developer allows files up to 2 GB and Enterprise removes the cap; Free, Pro, and Pro + Media show a plan overlay and cannot run it. Profile photos are well within these limits.
Is the photo uploaded anywhere?
No. Everything runs in your browser — bytes are read, scanned, and zipped locally and nothing is uploaded or retained. A private photo you are checking never leaves your device.
How can I at least confirm the file is what it claims to be?
Run it through magic-byte-validator to check the declared type against the actual signature, and hex-header-inspector to view the raw header. This carver only extracts previews; it does not verify file type.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.