DEV Community: Follower Change

Comparing Snapshots Without Lying to Yourself: The Set Logic of Follower Changes

Follower Change — Fri, 23 Oct 2026 17:22:46 +0000

Every follower tracker answers its questions with set operations, whether it admits it or not. When we built the historical comparison in Follower Change, the engineering turned out to be the easy part — a few set differences over normalized username lists. The hard part was epistemology: making sure the words in the UI never claimed more than the sets could prove. This post is the data model, and the honesty rules that fall out of it.

Two lists, three questions

A platform data export gives you, for one moment in time, two sets:

F — your followers
G — accounts you follow ("following")

From a single export, exactly one comparison is sound:

G \ F — accounts you follow that don't follow you back. This is a statement about now.

Nothing in a single snapshot describes change. Change requires two exports of the same list at different times — say F₁ (earlier) and F₂ (later):

F₂ \ F₁ — accounts present later that weren't there before: new followers (or returners).
F₁ \ F₂ — accounts present before that are absent now.

That second set is where the lying starts.

Absence is not an action

F₁ \ F₂ is routinely labeled "unfollowers." But set membership can't tell you why an element disappeared, and the possible causes are not interchangeable:

the person unfollowed you;
the account was deleted — by its owner, or by the platform;
the account was suspended;
the account was renamed, and the same person is sitting in F₂ under a new handle, possibly also appearing in F₂ \ F₁ as a phantom "new follower";
the export itself was partial — a split or truncated file can manufacture absences wholesale.

So the honest label for F₁ \ F₂ is "may have unfollowed" — or, in product language, "lost followers." Anything stronger ("X unfollowed you on Tuesday") is a claim the data cannot support, because exports are snapshots: they carry no event log and no timestamps for individual joins or leaves. Any tool that gives you an exact unfollow date from export data is interpolating — or inventing.

The rename case deserves emphasis because it corrupts both difference sets simultaneously: one departure and one arrival, both phantoms, for a single human who changed nothing about following you. Username-keyed diffing cannot detect it without stable account IDs, and most exports don't provide them consistently. A well-behaved tool says this out loud in its limits section instead of letting the numbers pose as certainty.

Normalization decides your error rate

Before any diffing, both snapshots pass through the same normalization, because exports are inconsistent in ways that masquerade as change:

Case: handles are case-insensitive on most platforms but exported inconsistently; lowercase everything.
The @ prefix: present in some formats, absent in others, occasionally present within a file. Strip it as a leading character only — an @ anywhere else is data.
Whitespace and empties: blank entries (trailing commas, empty JSON strings) are excluded, or your "new followers" list fills with ghosts.
Split files: some platforms shard large lists (followers_1.json, followers_2.json, …). Compare against the union of the shards — diffing against one shard manufactures thousands of fake departures.

Get normalization wrong and the set logic is flawless arithmetic over garbage.

A worked miniature

Earlier export F₁ = {ana, bilal, chen, dana}. Later export F₂ = {ana, chen, dana, eli}.

F₂ \ F₁ = {eli} — one arrival.
F₁ \ F₂ = {bilal} — one absence. Bilal may have unfollowed you. Bilal may also have deleted the account, been suspended, or renamed to "eli" — in which case both sets lied in opposite directions and the truth is zero change.

Four-element sets make this look trivial; at 40,000 followers the same ambiguity applies to every element, which is why reporting both numbers with their caveat attached is the entire game.

What we let the UI say

The rules we ended up with, stated as UI copy constraints:

Current-state language for single snapshots ("doesn't follow you back"), change language only for snapshot pairs.
Historical departures are "may have unfollowed," always — no exceptions for "obvious" cases, because the obvious cases are where the rename trap lives.
Exact dates are never attached to a departure. The export dates bound the window; that's all that can be claimed.
The limits ship next to the results, not in a FAQ nobody opens.

None of this requires exotic engineering — a Set, a normalize function, and the discipline to label outputs by what was actually computed. But it does require deciding, before you write the results screen, whether you're building a measurement tool or a story generator. Follower data is emotional; people read a departure list as a list of rejections. The least a tool owes them is not dressing set absence up as human intent.

Follower Change applies this model to the official exports of Instagram, TikTok, X, Threads, YouTube, Facebook, and LinkedIn — comparing snapshots locally in the user's browser, with the files never leaving the device.

Trust the Bytes, Not the Filename: Content Detection and Safe Parser Routing in the Browser

Follower Change — Fri, 23 Oct 2026 14:15:40 +0000

When a user uploads a data export to Follower Change, the file arrives with three claims about what it is: its name, its extension, and the MIME type the browser guessed. Our parser believes none of them. Everything it routes — a ZIP archive, JSON, an HTML export, a JavaScript data file, a CSV — is identified by its content, in a fixed order, before any parser is allowed to touch it. This post walks through that detection pipeline and the safety rules around it, because "what is this file?" is a security question, not a convenience.

Step 0: Read the head once, normalize it

Detection works on two views of the same bytes: the raw prefix for binary signatures, and a decoded text head for everything else.

// Mirrors production (lib/parser/detect.ts), lightly condensed.
const TEXT_HEAD_BYTES = 2048;

function textHead(bytes: Uint8Array): string {
  const head = bytes.subarray(0, Math.min(bytes.length, TEXT_HEAD_BYTES));
  return new TextDecoder("utf-8", { fatal: false }).decode(head);
}

The head is 2,048 bytes, decoded as UTF-8 with replacement (never throwing on invalid sequences), then trimmed and lowercased before matching. Lowercasing once, up front, means every rule after it can compare against lowercase patterns — export files do not respect your casing expectations, and Window.YTD is not a different format from window.ytd.

Step 1: Containers by magic bytes — the full signature

A ZIP archive announces itself in its first four bytes. We compare all four, against all three signatures a ZIP can open with:

// Production signatures, verbatim.
const ZIP_MAGIC: Array<[number, number, number, number]> = [
  [0x50, 0x4b, 0x03, 0x04], // standard zip — "PK\x03\x04"
  [0x50, 0x4b, 0x05, 0x06], // empty archive
  [0x50, 0x4b, 0x07, 0x08], // spanned archive
];

Checking a partial prefix is how a file that merely starts with the letters "PK" gets routed to an archive parser. Four bytes is the signature; anything less is a guess. If the magic matches, the file is an archive no matter what its name claims — and if it doesn't, no .zip extension can promote it later (the extension fallback below only applies when nothing in the content matched at all).

Step 2: Text formats by leading structure, in a fixed order

JSON, HTML, JavaScript data files, and CSV have no magic bytes, so the lowercased text head is matched structurally — in this exact order:

// Order mirrors production: JSON → HTML → X-JS → CSV → extension.
const head = textHead(bytes).trimStart().toLowerCase();

if (head.startsWith("{") || head.startsWith("[")) return "json";
if (head.startsWith("<!doctype html") || head.startsWith("<html")) return "html";
if (head.startsWith("window.ytd.")) return "xjs";   // X archive data files

// CSV: structural, explained below.
if (looksLikeSubscriptionsCsv(bytes)) return "csv";

// Nothing matched: the extension gets the last word, and only then.
switch (extensionOf(filename)) {
  case "json": return "json";
  case "html": case "htm": return "html";
  case "zip":  return "zip";
  case "js":   return "xjs";
  case "csv":  return "csv";
  default:     return "unknown";
}

(The CSV check and the helper names are simplified for readability; the order and the matching rules are the production ones. MIME types are never consulted anywhere in the pipeline.)

Order is not pedantry. A JSON payload can contain the string <html in a bio field; an X data file is JavaScript that is not JSON until its prefix is removed. The first matching rule wins, so the rules are sequenced from the most structurally certain to the least.

Step 3: CSV — the format with no signature

CSV is the honest problem child: no magic bytes, no doctype, no reliable opening token — and in our pipeline it carries two real exports: YouTube Takeout's subscriptions.csv and LinkedIn's Connections.csv (the latter identified by its path when it arrives inside LinkedIn's archive; the shared CSV reader handles both).

YouTube's header names vary by locale, so detection can't match a literal header string. What production matches is the shape of the first line: it must contain commas, and its first field must match /channel/i after trimming an optional opening quote — the one structural constant across localizations of "Channel Id, Channel Url, …".

Once routed, the CSV reader itself (a minimal RFC-4180-style parser: quoted fields, "" escapes, embedded commas and newlines) treats the file as hostile until proven otherwise: caps on total bytes (20 MB), rows (200,000), and field length (4,096 characters), with a hard failure — not a truncation — when a quoted field never terminates. A CSV from an export service is still an uploaded file, and uploaded files get limits, not trust.

Step 4: Routing is a security boundary

Detection's output is a route, not a verdict. Each route leads to exactly one parser, and each parser only ever sees bytes that claimed its shape:

The JSON route validates defensively — fields are typed as unknown and narrowed with guards; undocumented fields are ignored, documented ones type-checked.
The X-JS route never executes anything: the window.YTD.… = assignment prefix is stripped as text and the remainder is handed to JSON.parse. (This was the centerpiece of our earlier article, so here it gets one sentence — the point for detection is that a distinct route exists precisely so this file never reaches a JSON parser raw or an evaluator at all.)
The HTML route parses with a static parser and harvests profile links from anchor hrefs. The markup is never inserted into the DOM. An export file is untrusted input with a download button's good reputation.

Step 5: An archive is a bundle of untrusted files

A detected ZIP changes the question from "what is this file?" to "what is each file inside it?" Our archive layer (fflate, fully client-side) therefore re-runs detection per entry — the container's identity says nothing about its contents — and enforces, around that:

Traversal is impossible by construction: entries are never written to disk, and entries whose names contain .. segments, absolute paths, or drive letters are skipped outright.
Sizes are checked twice: each entry's declared size and the archive's declared total are capped before extraction, and the actual decompressed sizes are verified again after — a central directory can lie, so the defense doesn't rely on it.
The entry count is capped (200 in our configuration), turning pathological archives into a clear user-facing error instead of a frozen tab.

Step 6: Validate after routing, fail without leaking

Only after routing does validation begin, and its failures are designed to say nothing useful to an attacker: parse errors carry stable codes and user-safe messages, and never echo file contents back into the UI. "We know what this claims to be" and "this is well-formed" stay separate claims, checked by separate layers, in that order.

The pipeline, on one screen

Magic bytes first — full signatures, containers only.
A 2,048-byte, lowercased text head for everything else.
Structural matches in certainty order: JSON → HTML → X-JS → CSV.
Extension as fallback only; MIME never.
CSV detected by shape, parsed with hard caps.
One route per format; parsers validate defensively; HTML stays inert; JS data is text, never code.
Archives re-detect every entry, skip hostile names, and verify sizes twice.
Errors are stable, generic, and content-free.

Seven platforms ship our analyzer seven mutually inconsistent export formats. The detection pipeline is why the rest of the system never has to care which one a user is holding — and why a misnamed, mislabeled, or hostile file meets the same fixed sequence of questions before it meets any parser at all.

Seven platforms, seven export formats, one rule: the files never leave the browser

Follower Change — Thu, 22 Oct 2026 11:44:47 +0000

When we built Follower Change, the first architectural decision was also the constraint everything else had to survive: the analysis runs entirely in the user's browser. A follower export is someone's whole social graph. We didn't want it on our servers, so the parser, the comparison engine, and the results all live client-side. No upload endpoint exists for follower data — there's nothing to call.

That decision sounds simple until you meet the actual export formats. "Download your data" turns out to mean something different on every platform:

Instagram gives you JSON, but the shape depends on which list you asked for. Followers arrive as a top-level array of entries, each carrying string_list_data with a value (the username) and a timestamp. Following comes wrapped in a relationships_following object instead. And on larger accounts the followers list is split across shard files — followers_1.json, followers_2.json, and so on — which a user may upload one at a time. (An early lesson: shards from different platforms behave differently; our parser merges Facebook's shards and X's parts automatically, and we had to be explicit with users that Instagram's split files each need uploading.)

X doesn't give you JSON at all. Its archive contains JavaScript files:

window.YTD.follower.part0 = [ { "follower": { "accountId": "1252851", ... } }, ... ]

Executing that in the browser would be an obvious non-starter — uploaded bytes are untrusted input. We strip the window.YTD.<key>.part<N> = prefix as text and JSON.parse the remainder. Same rule everywhere in the pipeline: no eval, no DOM injection, no executing anything a user uploads.

HTML exports (Instagram offers one) get parsed inertly: we harvest instagram.com profile links and nothing else — no scripts run, no markup is rendered.

Underneath the formats, the pipeline is deliberately boring:

upload → validation → format detection → parser → normalize → dedupe → compare

Three details from that pipeline are worth stealing for any file-processing tool:

Never trust the MIME type or the extension. Format detection goes magic bytes → content sniffing → extension, in that order. Users rename files; platforms mislabel them.
Normalize usernames aggressively, but honestly. @Alice, Alice, and a full profile URL all canonicalize to alice before deduplication, or your comparison fills with phantom differences. But normalization has rules you can't invent: when we documented the spreadsheet version of this comparison, the correct formula removes @ only when it's the first character — blanket replaces corrupt usernames that legitimately contain odd characters.
Cap everything. ZIPs (we unzip in-browser with fflate) get a hard entry cap — ours is 200 entries — plus traversal guards, because an archive is just a polite name for a bundle of untrusted files. Oversized full-account archives are the common failure, so the error message tells users to upload the follower files directly instead.

What does the comparison itself look like once the data is clean? Two set operations, honestly labeled. Followers minus following (and vice versa) on a current export tells you who doesn't follow you back. Comparing two snapshots from different dates tells you which accounts were present before and absent later — and we label that "may have unfollowed" / "lost followers," never "unfollowed you," because absence from a later export doesn't prove intent, timing, or even that the account still exists. An analyzer that claims more than the data supports is lying to its users in a friendly font.

The browser-only constraint costs us things a server would make easy: no background processing for huge archives, no cross-device history unless a user saves a report to their account. We think it's the right trade. The data was never ours to hold.

If you want to try it: Follower Change works from the official exports of Instagram, Threads, TikTok, X, Facebook, YouTube, and LinkedIn. A free account includes 100 credits and an analysis costs 10 — the account exists for credits and saved reports; your follower files still never leave your browser.

I'm happy to answer questions about any of the export formats — especially if you've fought the X archive or TikTok's JSON before. Those two have the most surprises per kilobyte.