How to recover the original face behind a blurred or pixelated photo
- 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, which matters because the carver reads the whole file into memory before scanning.
- Step 2Drop the blurred or pixelated photo — The dropzone accepts any file type (
*/*) and processes one file at a time — there is no multi-file batch. Use the file you suspect was blurred in place: a JPEG exported from a phone editor, a redacted screenshot re-saved as a photo, or any container that might carry a stale preview. - Step 3Let the byte-carver scan — The tool walks the file's bytes from offset 1 looking 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 — the rules are fixed. - Step 4Read the result — If an embedded JPEG between 1 KB and 200 KB is found, the panel shows
bloband a Download button. If nothing qualifies, it shows the textNo embedded thumbnails detected in this file.— meaning no carvable preview leaked (it is not proof the blur is otherwise safe). - Step 5Download and open the carved previews — Click Download to save
<sourcename>-thumbnails.zip. Inside, each preview isthumb-0.jpg,thumb-1.jpg, … in byte order. Open each one and compare the face or plate against the blurred main image — a sharp, un-blurred copy is the leak. - Step 6If it leaked, strip the preview before publishing — This tool only extracts; it never removes. To delete the leaking embedded preview from a photo so a re-published copy is clean, run the original through exif-scrubber. Re-run this extractor on the scrubbed file to confirm it now reports no embedded thumbnails.
Will this recover the face? It depends on how the blur was applied
The carver only recovers a separate un-blurred preview if the editor left one. It cannot reverse the blur on the main image. These are the realistic outcomes.
| How the photo was redacted | Is an un-blurred preview left behind? | Result here |
|---|---|---|
| Blur applied, main image rewritten, EXIF preview untouched | Yes — the IFD1 JPEG still shows the original | Carved as thumb-0.jpg, un-blurred |
| Editor regenerated the preview from the blurred image | No — the new preview is also blurred | Either no in-bounds preview, or a blurred one |
| Whole file re-exported / stripped of metadata | No — preview removed entirely | No embedded thumbnails detected in this file. |
| Blur done by destroying pixels only (no embed) | No separate copy exists anywhere | Nothing to recover — this is not an AI un-blur |
| Preview stored as PNG/GIF, not JPEG | A preview exists but not as a JPEG stream | Not detected — carver reads JPEG markers only |
The exact byte rules the carver applies
Fixed values from the implementation — there are no user-adjustable options. A carved stream must satisfy all of these to be kept.
| Rule | Value | Effect for a leaked face/plate |
|---|---|---|
| Start marker | FF D8 FF after offset 0 | Finds the embedded preview while skipping the host file's own opening header |
| End marker, search window | FF D9 within 200,000 bytes of the start | Closes the carved JPEG; a preview with no nearby EOI is abandoned |
| Minimum kept size | greater than 1,024 bytes | A real un-blurred preview is comfortably larger than this; sub-1 KB runs are dropped as noise |
| Maximum kept size | less than 200,000 bytes | Keeps thumbnail-scale previews; a full-size embedded copy over 200 KB is skipped |
| Max thumbnails per file | 16 | Up to 16 carved JPEGs; a 17th in the stream 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 the hidden-thumbnail-extractor when checking a redacted photo.
| Aspect | Behaviour | Note |
|---|---|---|
| Minimum plan | Developer | Free / Pro / Pro + Media show a plan overlay and cannot run it |
| Per-file size limit | 2 GB on Developer; unlimited on Enterprise | Whole file is read into memory first, so large inputs are RAM-bound |
| Files per run | 1 | No batch mode — check one photo at a time |
| Accepted types | Any (*/*) | Works on raw bytes, so screenshots, exports, and odd containers all qualify |
| Where it runs | Browser only | The image's bytes never leave your device and are not retained |
Cookbook
Byte-level walkthroughs of what happens when you drop a blurred or pixelated photo. The Input / Result blocks describe markers and sizes, not literal binary.
Phone-blurred face, original still in the EXIF preview
A user blurs a face in a quick mobile editor that rewrites the main image but leaves the IFD1 thumbnail intact. The embedded preview still shows the un-blurred face.
Input: blurred-face.jpg (host SOI at offset 0)
... main image (face blurred) ...
APP1/EXIF IFD1 -> embedded JPEG preview (face sharp, 22 KB)
Scan: SOI at offset > 0, EOI within 200 KB,
size 22 KB -> 1 KB < 22 KB < 200 KB -> KEEP
Result: blurred-face-thumbnails.zip
thumb-0.jpg (the un-blurred original face)
findings.count = 1Redacted screenshot that the editor re-flattened
A screenshot is pixelated and re-exported by a tool that regenerates the preview from the edited pixels. No un-redacted copy survives.
Input: redacted-screenshot.jpg SOI (offset 0) main image (plate pixelated) ... regenerated preview -> also pixelated, 14 KB Scan: a preview exists, but it matches the redacted image Result: redacted-screenshot-thumbnails.zip thumb-0.jpg (pixelated -- no leak; redaction held)
Cleanly scrubbed file -- nothing to recover
A photo whose metadata (including the embedded preview) was stripped before sharing. There is no carvable JPEG after the host header.
Input: shared-clean.jpg SOI (offset 0) main image ... (no secondary FF D8 FF ... FF D9 in 1 KB-200 KB window) Scan: no qualifying embedded JPEG Result (text, not a download): No embedded thumbnails detected in this file.
Pixels destroyed in place -- not an AI un-blur
The face was blurred by overwriting pixels with no embedded copy anywhere. There is nothing for a byte-carver to find; this tool cannot reconstruct it.
Input: destructive-blur.jpg SOI (offset 0) main image (face permanently blurred) ... no embedded preview present Scan: nothing to carve Result (text): No embedded thumbnails detected in this file. (the original is genuinely gone; no recovery possible)
Found a leak -> strip it before re-publishing
Two-step privacy workflow: confirm the leak here, then remove the embedded preview so the published copy is safe.
Step 1 -- confirm the leak (this tool):
drop to-publish.jpg
get thumb-0.jpg in to-publish-thumbnails.zip
(face is un-blurred -> NOT safe to post)
Step 2 -- strip it (a sibling tool):
open /image-tools/exif-scrubber
drop to-publish.jpg -> removes EXIF incl. the preview
Step 3 -- re-check here:
drop the scrubbed file
get "No embedded thumbnails detected" -> now safeEdge cases and what actually happens
There is no separate un-blurred copy to recover
Not an un-blurThis tool carves a pre-existing embedded JPEG; it does not reconstruct detail from blurred pixels. If the editor blurred the main image and either regenerated or stripped the preview, no un-blurred copy exists and the carver correctly returns No embedded thumbnails detected in this file. That is a true-negative, not a failure.
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 window, the result is the plain text No embedded thumbnails detected in this file. and there is nothing to download. For a redacted photo this is the good outcome — it means no un-blurred preview leaked.
Preview stored as PNG, GIF, or BMP
Not detectedThe carver recognizes only the JPEG marker FF D8 FF. A preview encoded as PNG, GIF, or BMP has a different signature and will not be found, so the tool may report no thumbnails even though a non-JPEG preview exists. To inspect what the file actually contains at the signature level, use hex-header-inspector or magic-byte-validator.
Carved preview is itself blurred
Redaction heldIf the carver pulls a thumb-N.jpg but it shows the same blur as the main image, the editor regenerated the preview after blurring. The redaction held — there is no recoverable original. Compare every carved preview by eye; the count alone does not tell you whether the face leaked.
Embedded JPEG larger than ~200 KB
By designAny embedded JPEG of 200,000 bytes or more is skipped, because the upper bound is meant to keep output to thumbnail-scale previews. If you suspect a full-resolution un-redacted copy is embedded, inspect the raw bytes with hex-header-inspector — this carver will not extract it.
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 tiny preview just under 1 KB would also be dropped, so a real micro-preview can be missed.
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 or truncated preview with no EOI in that window is abandoned and the scan continues, 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 17th in-bounds preview is not included, so a 'count' of 16 should be read as 'at least 16'. This is rare for ordinary photos but possible after heavy re-editing.
File exceeds your plan's size limit
RejectedDeveloper caps each file at 2 GB; a larger file is rejected before scanning. Because the whole file is read into memory first, even an in-limit large file can fail on a low-RAM device — close other tabs or use a machine with more memory.
Original file integrity for evidence
PreservedExtraction is read-only — the tool reads the bytes through the browser and never writes back, so the source stays bit-identical. To prove the photo was not altered while you checked it, hash it before and after with multi-hash-fingerprinter; the digests must match.
Frequently asked questions
Can this un-blur or de-pixelate a face?
No. It is not an AI un-blur. It cannot reconstruct detail from blurred pixels. It only recovers a separate, unedited JPEG preview if the editor that blurred the main image left that preview behind. If no embedded copy exists, there is nothing to recover and the tool says so.
Why would an un-blurred face still be in the file?
Cameras and phones embed a small JPEG preview so galleries load fast. Many quick editors rewrite only the main image when you blur a face, and forget to regenerate that preview — leaving a copy of the original, un-blurred framing inside the file.
How do I know if my own redacted photo is safe to post?
Drop it here before publishing. If the carver returns No embedded thumbnails detected in this file., no JPEG preview leaked. If it pulls a clear thumb-N.jpg, your blur leaked — strip the preview with exif-scrubber and re-check here before sharing.
Does checking the photo modify it?
No — the process is read-only. The tool reads the file's bytes via the browser and never writes back, so the source stays bit-identical. You can confirm with multi-hash-fingerprinter by comparing the hash before and after.
What does 'No embedded thumbnails detected' mean for a blurred photo?
It means no JPEG preview between 1 KB and 200 KB was found after the host header. For a redacted image that is the safe outcome — no un-blurred copy leaked. It is not a guarantee the file is otherwise free of metadata.
What format are the recovered previews?
Always JPEG. Every carved stream is a JPEG, so each file in the ZIP is named thumb-0.jpg, thumb-1.jpg, and so on, regardless of the source file's type.
Can it find a full-resolution un-redacted copy, not just a thumbnail?
No. The carver keeps only JPEG streams under ~200 KB, so a full-size embedded copy is skipped by design. If you suspect a large embedded image, inspect the raw bytes with hex-header-inspector.
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. The dropzone accepts any file type, but only embedded JPEG previews in the 1 KB-200 KB window are extracted.
Can I check several photos at once?
No. The tool runs on one file per pass and the output ZIP is named after that single source file. Check photos sequentially.
What plan do I need and how large can the photo 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. The whole file is loaded into memory before scanning, so very large files are bounded by your device's RAM.
Is the photo uploaded anywhere?
No. Everything runs in your browser — the bytes are read, scanned, and zipped locally and nothing is uploaded or retained. That matters when the photo shows an identifiable person.
How do I permanently remove a leaking preview?
This tool only extracts. To delete the embedded preview and surrounding metadata from a photo, run the original through exif-scrubber, then re-run this extractor on the scrubbed file to confirm it reports no embedded thumbnails. You can also confirm the file's signature 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.