Is it safe to upload your Instagram data export?

There is a version of this question that is really a different question. Not "is it safe to
upload my export" but "why does anything need my file at all." Those have different answers,
and the second one is the more useful, so it is worth separating them before going any further.

This post is not an argument that you should use one particular tool. It is a method for
answering the question for whichever tool you are actually considering — including ours, which
is the only one where we can be precise about the answer because we can show you the code
path. Along the way there is a section on what to do if you have already uploaded an export
somewhere, which is the part people tend to skip and then worry about at 2am.

1. 30syou have the file and a tab open somewhere asking you to hand it over.
2. 5minthe three questions below, which settle most of it for any tool.
3. 10minverifying a local-processing claim in your own network tab.
4. 2minthe section on what to do if you already uploaded it somewhere.

Why this file is different from your other files

A photo library is intimate. This is a list.

The export does not just describe what you posted. It describes who you know, who you talk
to and when, what you searched for privately, where your account has been signed in from and by
which device, what you synced from your phone's contacts, and what Meta says it inferred about
you in order to decide what to show you. We have walked the whole cabinet in
What's actually inside your Instagram data export,
so we will not repeat it here. The relevant point for this post is narrower and worse:

Most of that is information about other people, not just about you. Your messages involve
the person you sent them to. Your connections folder is a list of everyone who followed you at
any point. Your synced contacts is your friends' and family's phone numbers and email
addresses, handed to a platform by you on their behalf.

That changes who the data belongs to, and it is the strongest argument in this whole post for
handling the file carefully. If you upload an export to a stranger's server, you have not only
handed over your own data. You have handed over a list of people who never agreed to it.

The three questions that settle it

Any tool that wants your export can be reduced to three questions, and a tool worth using will
survive all three being asked directly and answered in writing.

Is it processed on a server, or in your browser? These are completely different products
wearing the same interface. Server-side means your file crosses a network and lands on hardware
you do not control, run by people you have never met, in a jurisdiction you did not choose.
Browser-side means the code runs on your machine and the bytes never move. This is the question
that matters most, and it is the one most often answered in marketing language rather than
plain ones.

Is it kept after it has been processed? Plenty of tools are genuinely in the business of
not retaining your file. Also plenty process it on a server and keep it for debugging, or for a
model, or "for a few weeks", or indefinitely as a side effect of a backup nobody remembers
enabling. Retention is a separate decision from processing and it is the one that creates the
long-term exposure.

Is anything derived from it used to train anything? Not the file — the derivatives. Counts,
outcomes, embeddings, summaries. An archive that is deleted on request has already had
inferences made from it, and those inferences may persist in ways the deletion does not reach.

How to verify it yourself, in about a minute

This is the part that removes the need to take anyone's word for anything, including ours, and
it is worth doing with a tool you currently trust before you do it with one you do not.

Open your browser's developer tools, switch to the Network panel, and clear it. Then load
the export as you normally would and watch what happens while it is being read.

If you would rather not read developer tools at all, there is a cruder version that catches
most things: disconnect from the internet and load the export. A genuinely local tool works
completely offline, because there is nothing left for it to talk to. Anything that needs a round
trip will either fail outright or fall back to something thinner. Our own site is a static
export and the reading path is a Web Worker, so it will do this happily.

What "it stays on your device" does and does not mean

Local processing is a strong property and it is worth being as clear about its edges as about
its centre, because a claim that hides its edges is not a claim you should rely on.

None of these are reasons to avoid local tools. They are reasons to prefer local tools and
keep your browser clean, which is a much shorter list of responsibilities than trusting a
stranger with your messages.

What LMKFR actually does, specifically

Because we can point at the code, here is the mechanism rather than the promise.

The export is read in a Web Worker in your tab. When you drop the ZIP, the bytes are read
with the browser's own file API and handed to a worker thread, which parses them and posts
results back to the page. There is no upload step anywhere in that path because there is no
endpoint to upload to — every route handler in this project is for the optional claim or sync
features, and none of them reads a multipart body or a ZIP.

The search index is cached in your browser's own storage, against the archive it belongs
to, so a second visit is instant instead of re-parsing a large file. That index contains
derived text and counts. It lives on your machine, and clearing site data deletes it.

Media is opened from the local archive. Photos, videos and audio are read straight out of
the folder you imported, in the browser, and never copied anywhere.

The optional features are separate, off by default, and stated plainly. If you register
for the optional public profile, we hold your username, your email encrypted at rest with only
a keyed index of it queryable, a hash of your password, and the aggregate counts that make up
your own snapshot — nothing from the archive itself. If you separately opt in to cross-device
sync, that tier stores an encrypted, media-stripped lean profile, and messages are included
only if you explicitly say so. Both are off unless you turn them on, and neither is required to
read your archive.

And one disclosure that most sites would leave out. This page makes no automatic request at
all beyond the security-policy violation report your browser may send if something tries to
load a resource it should not. That report contains the URL that tripped the policy — never
archive content, never a filename from your export. It is written to a server log for debugging
and then discarded; nothing is persisted, forwarded to a third party, or stored. We would
rather you knew that one request exists than be told, and later find it in a network tab,
that there were none.

If you already uploaded it somewhere

Regret here is usually about the unknown rather than the act, so the useful thing is to replace
the unknown with facts.

Find out whether they kept it. If the tool has an account, a deletion button or a support
address, use one of them and keep the confirmation. A tool with no deletion path is telling you
something about itself that no privacy policy will.

If they retained it, ask for it back or for its deletion in writing, and expect the answer
to depend on the jurisdiction you live in rather than on goodwill. Data protection law in the EU
and UK gives you a right of access and a right to erasure, both on deadlines.¹ The same
request sent in writing is much harder to ignore than a form submission.

Change nothing about your account until you know whether the export included credentials.
It does not — your export is your activity and profile data, not your password — but your
passwords, session cookies and two-factor secrets are worth rotating as ordinary hygiene,
particularly if the service in question was unfamiliar.

Then re-request the export if you need to be sure of what you still hold. An export
reflects what the platform holds when you ask, so a fresh one is the current truth. Keeping
both is genuinely useful, because the difference between them is the interval in which
something changed.

What to do instead

The practical version, if you would rather not read the sections above.

Read it locally. It turns out to be entirely possible, which is the reason this post
exists rather than the other way round. You need a
folder, a browser, and no account.

Ask three questions before you hand anything to anyone, and accept vague answers as a
refusal.

Prefer tools that work offline. The offline test above is the fastest verification there
is, and it cannot be faked by a privacy policy.

If a tool does need a server, find out what it stores and for how long, and whether you can
delete it. That is a normal question to ask and being treated as unreasonable for asking it is
itself an answer.

And if you are under 13, or were when some of this happened: Instagram's minimum account age is
13.³ An export can easily contain material from before an account existed, including
childhood-era memories, which makes this particular file the one most worth keeping off other
people's servers. Reading your own archive on your own device does not involve us at all.

Questions this comes up

Where the sourced version lives

The claims about what the export contains are covered in full in
What's actually inside your Instagram data export,
including which parts of it are stored and which are calculated. The claims about us are
checkable directly: every route handler in this project is small enough to read, and the ones
that exist are for the optional claim and sync tiers, which are described above rather than
buried in a settings page.

²: Meta Data Policy — the definition of "information about you" from which
the export is drawn, and therefore the honest boundary of what a request can return. It is also
the reference for whose information that is: an export about your account carries data about
other people. <https://www.facebook.com/privacy/policy/>
¹: Regulation (EU) 2016/679 (GDPR), Articles 15 and 17 — the rights of access and
erasure, both on defined deadlines. <https://eur-lex.europa.eu/eli/reg/2016/679/oj>
³: Meta's Terms of Use set the minimum account age at 13. The current version is at
<https://help.instagram.com/581066165581870>

LMKFR is an independent project. It is not affiliated with, endorsed by, or associated with
Instagram or Meta, and it works only with a file you already hold. Nothing on this page is
collected, and every claim above is either checkable in the code or in your own browser.