How to forensic hidden thumbnail extractor
- Step 1Confirm you are on a Developer (or higher) plan — This is a Developer-tier tool. On Free, Pro, or Pro + Media plans the page shows a plan overlay and the dropzone is disabled. Developer raises the per-file limit to 2 GB, which matters here because the carver reads the entire file into memory before scanning.
- Step 2Drop one file onto the extractor — The dropzone accepts any file type (
*/*). This tool processes one file at a time — it does not accept multi-file batches. Good candidates: camera JPEGs, edited JPEGs/PSDs, exported video files, or any container you suspect carries a stale preview. - Step 3Let the byte-carver scan — The tool reads the file into a byte buffer and walks it looking for embedded JPEG streams: a
FF D8 FFStart-of-Image marker that is not at offset 0 (offset 0 is the host file's own header), followed within 200 KB by aFF D9End-of-Image. No options to set — there are no controls, presets, or format pickers. - Step 4Read the result — If embedded JPEGs are found, the result is a binary ZIP — the panel shows
bloband a Download button. If none are found, the panel shows the plain-text messageNo embedded thumbnails detected in this file.The metrics line reports bytes in, bytes out, and processing time. - Step 5Download and unzip — Click Download to save
<sourcename>-thumbnails.zip. Inside, each carved preview is namedthumb-0.jpg,thumb-1.jpg, … in the order they appear in the file's bytes. A single file can yield up to 16 thumbs; anything beyond the 16th is not extracted. - Step 6Compare each preview against the visible image — Open each
thumb-N.jpgnext to the rendered source. A crop, a different color grade, a visible face or license plate that is redacted in the main image, or a different aspect ratio in the preview are all signs the embedded copy predates an edit. To then strip the leaking preview from the file, hand the original to a metadata remover such as exif-scrubber — this tool only extracts, it never removes.
What the carver looks for and what it keeps
The extractor is a raw-byte JPEG carver, not a per-format parser. These are the exact rules it applies, taken from the implementation. There are no user-adjustable options — every value below is fixed.
| Rule | Value | Why it is set this way |
|---|---|---|
| Start marker | FF D8 FF (JPEG Start-of-Image) | Every embedded JPEG preview — EXIF/IFD1, MPF, PSD resource, video atom — begins with this. The scan starts at byte offset 1 so it skips the host file's own opening SOI at offset 0 |
| End marker | FF D9 (JPEG End-of-Image) | Marks the close of a carved JPEG stream. The carver searches forward from each SOI for the first EOI |
| EOI search window | 200,000 bytes from the SOI | Caps how far the carver looks for the closing marker, so a missing EOI in a corrupt blob doesn't run the scan to the end of a multi-GB file |
| Minimum kept size | greater than 1,024 bytes (1 KB) | Rejects tiny FF D8 FF ... FF D9 runs that are coincidental byte patterns rather than real previews |
| Maximum kept size | less than 200,000 bytes (~200 KB) | Embedded previews are small by definition; this upper bound keeps full-resolution JPEGs that happen to be embedded out of the thumbnail set |
| Max thumbnails per file | 16 | The result is truncated to the first 16 carved JPEGs; a 17th preview in the byte stream is not extracted |
| Output extension | always .jpg | Every carved stream is a JPEG, so each file in the ZIP is thumb-N.jpg regardless of the source container |
Where the previews this tool finds actually live
The carver does not parse these structures — it finds them because each stores its preview as a self-contained JPEG. This table maps the forensic source to why the byte-scan reaches it.
| Source | How the preview is stored | Found by the byte-carver? |
|---|---|---|
| JPEG EXIF thumbnail (IFD1) | A small standalone JPEG inside the APP1/EXIF block | Yes — it is a FF D8 FF ... FF D9 stream after the host SOI |
| JPEG MPF (Multi-Picture Format) | One or more additional full JPEG images appended after the primary | Yes, if each is within the 1 KB–200 KB keep window; larger primary copies are skipped by the 200 KB cap |
| PSD image-resource thumbnail | A JPEG-compressed preview in an image-resource block | Yes — stored as a JPEG stream the scan can locate |
| Video / RAW container preview | JPEG preview embedded in a metadata atom or maker-note | Yes when present as a JPEG within size bounds; this tool does not decode video frames |
| PNG / GIF / BMP preview | Stored in a non-JPEG format | No — the carver only recognizes JPEG SOI/EOI markers, not PNG/GIF signatures |
| Full-resolution embedded image | A JPEG larger than ~200 KB | No — exceeds the 200 KB maximum and is treated as a main image, not a thumbnail |
Plan, input, and output behaviour
Operational facts for the hidden-thumbnail-extractor. Security-family limits apply per file; this tool runs only in the browser.
| Aspect | Behaviour | Note |
|---|---|---|
| Minimum plan | Developer | Free / Pro / Pro + Media show a plan overlay; the tool will not run below Developer |
| Per-file size limit | 2 GB on Developer; unlimited on Enterprise | The whole file is read into memory before scanning, so very large inputs are RAM-bound by your browser |
| Files per run | 1 | No multi-file batch — process inputs one at a time |
| Accepted types | Any (*/*) | The carver works on raw bytes, so it is not restricted to image extensions |
| Output (found) | ZIP blob: <sourcename>-thumbnails.zip | Contains thumb-0.jpg … up to thumb-15.jpg |
| Output (none found) | Plain text: No embedded thumbnails detected in this file. | Shown in the result panel; nothing to download |
| Where it runs | Browser only | No server-side path; bytes never leave your machine and are not retained |
Cookbook
Concrete byte-level walkthroughs of how the carver behaves on real forensic inputs. The Input / Result blocks describe markers and sizes, not literal binary you would type.
Camera JPEG with a stale EXIF preview after a crop
A photographer crops a JPEG in a quick mobile editor that rewrites the main image but leaves the EXIF IFD1 thumbnail untouched. The embedded preview still shows the original uncropped framing — the forensic mismatch this tool exists to surface.
Input: edited-photo.jpg (host file, own SOI at offset 0)
... main JPEG image data (cropped) ...
APP1/EXIF IFD1 → embedded JPEG preview (uncropped, 18 KB)
Scan: SOI found at offset > 0, EOI within 200 KB,
size 18 KB → 1 KB < 18 KB < 200 KB → KEEP
Result: edited-photo-thumbnails.zip
thumb-0.jpg (the uncropped original framing)
findings.count = 1Multi-Picture (MPF) file yields several frames
A phone or mirrorless camera writes an MPF JPEG: a primary image plus extra embedded JPEG frames (e.g. a depth or wide-angle companion). Each embedded frame within the size window is carved separately.
Input: mpf-capture.jpg
SOI (offset 0) primary image ... (large, > 200 KB)
MPF frame A → embedded JPEG, 42 KB
MPF frame B → embedded JPEG, 51 KB
Scan: primary at offset 0 is skipped (host header)
frame A: 42 KB → KEEP
frame B: 51 KB → KEEP
Result: mpf-capture-thumbnails.zip
thumb-0.jpg (frame A)
thumb-1.jpg (frame B)
findings.count = 2Clean file — nothing to carve
A re-saved or freshly exported file whose toolchain regenerated (or stripped) the preview. The scan finds no in-bounds embedded JPEG after the host header, so there is no ZIP — just a text message.
Input: re-exported.jpg SOI (offset 0) main image ... (no secondary FF D8 FF ... FF D9 in the 1 KB–200 KB window) Scan: no qualifying embedded JPEG found Result (text, not a download): No embedded thumbnails detected in this file.
Oversized embedded JPEG is treated as a main image, not a thumbnail
A container holds a full-resolution second JPEG that is larger than ~200 KB. By design that is not a thumbnail, so the carver's upper bound excludes it. This is a deliberate limit, not a bug.
Input: combined.bin host header ... embedded JPEG #1 → 12 KB → KEEP (thumbnail-sized) embedded JPEG #2 → 640 KB → SKIP (> 200 KB max) Scan: #1 within bounds, #2 over the 200 KB ceiling Result: combined-thumbnails.zip thumb-0.jpg (only the 12 KB preview) findings.count = 1
Extract first, then strip the leak from the original
Two-step forensic workflow: pull the previews here to document what leaked, then remove the embedded metadata so a re-published copy can't leak it again. This tool only extracts; the removal step belongs to a metadata scrubber.
Step 1 — document the leak (this tool):
drop leaked.jpg
get leaked-thumbnails.jpg in leaked-thumbnails.zip
(preview shows a face redacted in the main image)
Step 2 — strip it from the original (a sibling tool):
open /image-tools/exif-scrubber
drop leaked.jpg → removes EXIF incl. the IFD1 preview
Result: a published copy with no recoverable stale preview.Edge cases and what actually happens
No qualifying embedded JPEG in the file
By designWhen the scan finds no secondary FF D8 FF ... FF D9 stream within the 1 KB–200 KB size window, the result is the text No embedded thumbnails detected in this file. — there is no ZIP to download. This is the expected, correct output for files whose preview was regenerated, stripped, or stored in a non-JPEG format. It is not proof the file is 'clean' of all metadata; it only means no carvable JPEG preview was present.
Preview stored as PNG, GIF, or BMP
Not detectedThe carver recognizes only the JPEG SOI marker FF D8 FF. A preview encoded as PNG, GIF, or BMP has a different signature and will not be found — the file may report 'no thumbnails detected' even though a non-JPEG preview exists. For signature-level inspection of what a file actually contains, use hex-header-inspector or magic-byte-validator.
Embedded JPEG larger than ~200 KB
By designAny embedded JPEG of 200,000 bytes or more is skipped — the upper size bound deliberately excludes full-resolution copies so the output is thumbnails, not a second full image. If you are hunting an embedded full-size image rather than a preview, this tool is the wrong instrument; inspect the raw bytes with hex-header-inspector instead.
Embedded JPEG smaller than 1 KB
By designCarved streams of 1,024 bytes or fewer are rejected. Tiny FF D8 FF ... FF D9 runs are usually coincidental byte patterns, not real previews, so the lower bound suppresses false positives. A genuine but unusually small preview just under 1 KB would also be dropped.
More than 16 previews in one file
TruncatedThe result is capped at the first 16 carved JPEGs in byte order. A file with a 17th in-bounds preview will not include it. This is rare outside heavily-edited PSDs or unusual MPF stacks, but it means a 'count' of 16 should be read as 'at least 16', not 'exactly 16'.
Missing or far-away End-of-Image marker
SkippedAfter an SOI, the carver searches forward at most 200,000 bytes for the closing FF D9. If a corrupt or truncated preview has no EOI within that window, that candidate is abandoned and the scan moves on. A real preview with a damaged trailer therefore may not be recovered.
JPEG nested inside an already-carved preview
Not re-scannedAfter a match the scan resumes immediately past the carved stream's EOI, so it does not look for additional SOI markers inside a JPEG it has already extracted. A thumbnail-within-a-thumbnail (an embedded JPEG that itself carries an EXIF preview) yields only the outer one from a single pass.
File exceeds your plan's size limit
RejectedDeveloper caps each file at 2 GB. A larger file is rejected before scanning with an over-limit message; Enterprise removes the cap. Because the whole file is read into memory first, even an in-limit multi-GB file can fail on a low-RAM device — close other tabs or work on a machine with more memory.
Run attempted below the Developer tier
Plan requiredOn Free, Pro, or Pro + Media the page renders a plan overlay and the dropzone is disabled — the extractor will not process anything. Upgrade to Developer (or Enterprise) to enable it. Other forensic siblings like magic-byte-validator and entropy-analyzer are available on lower tiers if you only need file-type or randomness checks.
Original file integrity for chain of custody
PreservedExtraction is read-only: the tool reads the file's bytes through the browser and never writes back, so the source remains bit-identical. To prove that to a reviewer, hash the file before and after with multi-hash-fingerprinter — the digests must match because nothing about the source changes.
Frequently asked questions
Does this tool parse MP4 udta atoms or PSD layer panels specifically?
No. It is a raw-byte JPEG carver, not a per-format parser. It scans the whole file for embedded JPEG streams (a FF D8 FF start marker after offset 0, closed by a FF D9 within 200 KB) and extracts the ones between 1 KB and 200 KB. It finds previews in videos and PSDs because those previews are stored as JPEGs — but it does not decode the container's atom or layer structure. If a preview is not a JPEG, this tool will not see it.
Why would a photo carry a hidden thumbnail at all?
Cameras and operating systems embed a small JPEG preview so galleries can render fast without decoding the full image. The forensic value is that an editor can change the main image and forget to regenerate that preview — leaving a copy of the earlier crop, color, or un-redacted content behind.
Does extracting modify or damage the original file?
No. The process is read-only — the tool reads the file's bytes via the browser File API and never writes back. The source stays bit-identical, which you can confirm by comparing hashes before and after with multi-hash-fingerprinter.
What does 'No embedded thumbnails detected in this file' actually mean?
It means the scan found no JPEG stream after the host header that fell within the 1 KB–200 KB size window. That can happen because the file genuinely has no preview, because the preview was regenerated or stripped, because it is stored in a non-JPEG format, or because it is larger than ~200 KB. It is not a guarantee the file is free of all metadata.
How many thumbnails can it pull from one file?
Up to 16. The result is truncated to the first 16 carved JPEGs in byte order, so a 'count' of 16 should be read as 'at least 16'. Most files have one (the EXIF preview); MPF and multi-preview PSDs can have several.
What format are the extracted thumbnails?
Always JPEG. Every carved stream is a JPEG by definition, so each file in the ZIP is named thumb-0.jpg, thumb-1.jpg, and so on, regardless of the source container's type.
Can it find an embedded full-resolution image, not just a thumbnail?
No — that is excluded on purpose. The carver keeps only JPEG streams under ~200 KB, so a full-size embedded JPEG is skipped. If you need to inspect or locate a large embedded image, examine the raw bytes with hex-header-inspector.
Do I need to pick a format or set any options?
No. There are no controls, presets, or format pickers — you drop one file and the carver runs with fixed rules. The dropzone accepts any file type, but only embedded JPEG previews in the size window are extracted.
Can I process several files at once?
No. This tool runs on one file per pass. Process inputs sequentially; the output ZIP is always named after the single source file you dropped.
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. Because the whole file is loaded into memory before scanning, very large files are bounded by your device's available RAM.
Where does processing happen — is anything uploaded?
Everything runs in your browser. The file's bytes are read locally, scanned locally, and zipped locally; nothing is uploaded to a server or retained. That matters when the evidence is sensitive.
I extracted a leaking preview — how do I remove it from the file?
This tool only extracts; it never removes. To strip the embedded preview and surrounding metadata from a photo, run the original through exif-scrubber. For a quick before/after sanity check on what changed, you can also confirm the file's signature and structure with magic-byte-validator.
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.