Photos & RAW · TIFF candidate
TIFF header found but the image is incomplete
Is a TIFF recovered when only its header is valid?
Short answer
Not yet. A valid byte-order mark and first image directory only show where a TIFF begins; strips, tiles and later directories can sit further on and be missing or cut off. Count the file as recovered only when the whole image decodes at its full size and every offset points inside the recovered data.
The situation
A scanner recognizes TIFF byte order and an initial directory, but the image does not fully decode.
A byte-order mark and a first image directory show where a TIFF starts; they say nothing about how far it reaches. Since the raster is split into strips or tiles stored well beyond that point, a header hit is a candidate and not yet a recovered file.
01 / Diagnose
Work out what actually disappeared
The header names the byte order and points to the first image file directory. That directory carries tags with offsets to the picture data and, optionally, to further directories for additional pages. Each of those offsets is an absolute position in the file, so if the recovered extent ends early, the offsets point into nothing. Structural checks pass while decoding stops.
TIFF strips, tiles, and later IFD data can live beyond the header and may be missing or wrongly bounded.
Check the last known path, trash and backups without writing to the original device.
02 / Protect the source
Preserve the best recovery chance
- 1
Keep the candidate exactly as exported and work on a copy, so the original byte range stays available for comparison.
- 2
Read the tags for image width, height and strip or tile offsets and check whether they fall inside the recovered length.
- 3
Return to the source medium while it is unchanged and rescan it read-only, allowing a larger extent per candidate.
- 4
Export the new attempt next to the old one and decode both fully before deciding which version to keep.
Do not open and save the candidate in an image editor to make it valid, and do not convert it to another format as a test. Either action writes a new file whose length reflects the damage instead of the original, and the comparison you need is then gone.
03 / Choose the method
Match the tool to the source
For stable, readable exFAT, NTFS and FAT16/FAT32 or uncompressed IMG, DD, RAW and BIN images.
Unconfirmed exports are marked .UNVERIFIED.
File Recovery Hero recovers whole files from readable exFAT, NTFS and FAT16/FAT32 sources read-only; it does not repair a TIFF whose strips are missing and does not stitch fragments together. If the medium no longer delivers those blocks, no scan setting produces them.
04 / Verify
Check the recovered content, not just its name
Count the file as recovered only when it decodes to the width and height its own tags declare, every strip or tile renders, and any further page opens as well. Offsets reaching past the end of the file, or a raster ending in a flat block, both mean the extent is too short.
Keep the source until two verified copies exist. One working preview is not enough.
Sources and technical references
FAQ
Questions about this recovery case
Can TIFF candidate be recovered in this situation?+
A byte-order mark and a first image directory show where a TIFF starts; they say nothing about how far it reaches. Since the raster is split into strips or tiles stored well beyond that point, a header hit is a candidate and not yet a recovered file. The result still depends on what remains readable on the source.
What should I avoid before scanning?+
Do not open and save the candidate in an image editor to make it valid, and do not convert it to another format as a test.
Does scanning write to my memory card?+
Your memory card is only read. Nothing is saved to it.
How do I know whether the result is complete?+
Count the file as recovered only when it decodes to the width and height its own tags declare, every strip or tile renders, and any further page opens as well.