Why your Instagram export won't open, and what to do instead
Four distinct ways an Instagram export can fail to load, and how to tell a hostile file from a hard cap, a broken preview from gradual loading, and an automatic re-parse from a bug.
The same error message can be covering four very different problems, and the advice for
each is nearly opposite. An export that will not open is almost always one of: it is not
the file Meta actually gave you; the parser is stopping something it is built to stop;
one part of it is silently missing rather than broken; or the app is doing something it
is supposed to do and making it look like corruption. Telling those apart is faster than
one generic "try re-requesting it."
Before anything else, check the obvious — the file is the original ZIP Meta produced.
If it is not, that is the answer. If it is, the failure is one of three specific, named
cases: a hostile-file guard firing on legitimate input, media that loads on a delay, or an
automatic re-parse after a code change. None of those are corruption. They are, in order,
the tool protecting itself, the tool being patient on purpose, and the tool repairing
itself rather than serving stale parsing.
- 30sthe one question that sorts most of these: is this the original
.zip, untouched. - 3minthe three other causes, in the order they actually appear.
- afterwards — why the tool refuses some of what you hand it, and what it will never tell
- you is "broken" about your file.
Case one: the file is not the export
A Meta export is a single archive. The moment it is extracted and re-compressed to a
new ZIP, it stops being a Meta export to a parser that inspects the package — and an
"untrusted archive" warning is not a missing feature. It is the parser refusing to read
a file it cannot be certain about.
The same applies to a ZIP produced by a third-party tool: LMKFR reads Meta's own format,
and a format another app claims is "the same thing" is not. When in doubt, open the file
in your file manager and look for the folder structure this site describes. If it does not
match, the file is not what we are about to parse.
Case two: the guard is working as designed
LMKFR is built to turn away the parts of this format that are structurally hostile, and
it will report that as a failure even when the user experience "could not open it" is not
what you wanted to hear. The defences fire before a single record is decoded:
- Path traversal. Every entry name is checked against a hostile shape before anything
is written to disk, so a ".." escaping the folder, an absolute path, or a null-byte
entry never reaches the extract step. - Decompression bombs. There is a cap on how much a single entry, and the whole
package in aggregate, is allowed to expand from. A small
.zipthat would
decompress to an unbounded amount of data is rejected on that arithmetic, not on
whether its contents look busy. - Count and size caps. Enough entries, or enough total bytes, and the tool treats
the archive as unreadable rather than spend every byte of your memory on it.
These are not telltales that your archive is dangerous. They are thresholds a hostile
archive would try to exploit, and a legitimate archive is simply far below them — so
when one of them fires on a file you know is yours, the right response is to look for
which file or entry is wrong rather than to assume the archive is unreadable.
Case three: it is loading, not broken
An export is text plus a large amount of media, and the app treats the two differently on
purpose: the text is parsed first because it is what you actually read, and the media
waits its turn in the background. Three consequences follow, and all three look like
failures to the unreasonable eye.
- A photo that is not there yet is not missing. It is still in the background queue;
the UI will reflect it when its turn comes. The fastest confirmation is the media
count in the folder growing after the text already appeared. - A thumbnail that failed to render is not a lost image. The record that says the
image belonged to a post still exists, even if the preview could not be fetched
because the signed URL expired before the tool reached it. - Your storage is not infinite. Browser storage, and iOS in particular, evict media
caches under pressure. If a photo from yesterday is already gone, that is the sandbox
being polite about a file that lives on your machine, not the parser losing data.
None of this is corruption, and none of it is fixable by asking for the export again. It
is the shape of a deliberate, text-first streaming parse.
Case four: it re-parsed itself, on purpose
The parser is versioned. When the parsing code in the app is improved — a stricter
timestamp, a new reaction emoji, a label the metadata now carries through differently —
the tool notices that the copy you already imported is older than what the current code
produces, and it re-parses rather than letting a stale parse stand for your record. The
copy on disk is replaced by the corrected one. Nothing was lost to a crash; the archive
is being re-read so the picture of it is current.
The three causes to check in order
| Symptom | First explanation to rule out |
|---|---|
| "It does not look like an Instagram export" | The file is not the original `.zip`, or it is a third-party export. |
| "It opened but there is no media" | It is still in the background queue — wait, or reload to resume. |
| "It opened and the app re-ran the parsing" | A parser upgrade re-stamped the import; this is maintenance, not a fault. |
The one thing we will never tell you it can fix by re-requesting
If the original export was built around some missing category, the 4-day window you
spent parsing does not change what Meta wrote. A new request with the same folder
ticked will return the same absence. Getting it right has to happen at the request
screen, which is why this is the second entry in the series and not a footnote.
Questions this comes up
The app says my file is not an Instagram export. What next?
Check the two things only that tell. First, that it is a .zip, not an extracted folder
you later compressed. Second, that it is the file Meta produced, not one another tool
rebuilt. LMKFR parses Meta's format directly; a rebuilt or re-zipped package is exactly
the case that warning exists for.
Why do some photos only appear much later?
Because the app parses text first and handles media in the background. A record that
says a photo exists can appear before the photo does. The media counter in the folder
grows across that parse; if it has, the archive is complete and the file you are
waiting on has entered the queue.
Why does the app sometimes re-parse my archive on its own?
The parser leaves a version stamp on each import. When the shipping code is newer than
that stamp, the app re-parses rather than serve a record computed by older code. The
replacement is the same archive, rerendered against the current parser — it is not a
data loss event.
Can a corrupt ZIP contain useful data?
If there is an error on open, the archive is not in a supported state. The defences
that catch it are not filtering; they are refusing an entry pattern that is unsafe to
evaluate, or a total size that is not memory-safe. Once it trips those, there is no
payload to salvage.
Where this was checked
The refusal behaviour, the caps and the media queue are all observable in the source:
the entry-name and byte-count checks sit in packages/shared/src/parsers/export-guard.ts,
the zip reader and its size arguments in zip-handler.ts, and the media re-queue after
a parser upgrade is the version-stamp logic in packages/shared/src/layers/stamps.ts.
Where the prose names a rule, the rule sits at that module, not in the README.