X (Twitter) Unfollowers Checker: Compare Lists Without Guessing

Use the Follower & Connection List Checker with X selected. Decide between a relationship comparison and snapshots before loading files. This guide follows an archive based workflow, explains why numeric account IDs cannot be matched directly to handles, and works through two examples. Processing stays in your browser: the checker does not sign into X, fetch profiles, discover usernames, or perform account actions.

Decide whether you need history or a current relationship comparison

Start with the question you can actually support. If you want to find accounts in your following list that are not in your follower list, choose relationships. Source A is Following and source B is Followers. The A only bucket means Not in follower list. It does not mean those accounts followed you previously. A publication you have followed for years might never have followed your account at all.

If you want to inspect change over time, choose snapshots instead. Put the earlier follower list in A and the later follower list in B. The results are Absent from later list, Added to later list, and Present in both. Use follower lists on both sides. Comparing an earlier following file with a later follower file changes the underlying question and makes a historical reading misleading.

One archive can provide material for a relationship comparison because it may include both followers and following. It cannot create a missing historical baseline. If today is your first collection, preserve it as the starting snapshot. A second collection later gives you the two observations needed for a comparison. A current count, a remembered username, or a screenshot of a total does not supply the missing identities.

Write the intended comparison in one sentence before importing anything. For example: compare the follower account IDs in the studio’s September archive with follower account IDs in its October archive. This fixes the account, list type, identity type, and order. It also gives you a direct way to notice a misplaced file before a convincing chart encourages you to interpret the wrong comparison.

Extract the relevant X archive files, not the whole download

X provides a native archive request through account settings. Its Help Center describes identity verification, a request for data, and a notification when the download is ready. The archive includes follower and following information among many other categories. Request your own archive through that native process. The free checker does not request it for you, bypass verification, or retrieve a complete list from a public profile address.

Download and extract the ZIP locally. Within the extracted data, look for the follower and following files, commonly named follower.js and following.js. Read the included archive description if the folder contains several parts or unfamiliar names. Select the files that belong to the intended category and collection. Do not add posts, messages, likes, or the archive’s browsing interface simply because they are in the same folder.

The checker accepts supported X archive JavaScript wrappers as data. A follower file can contain an assignment beginning window.YTD.follower.part0 =, followed by an array of records. A following file uses the corresponding following wrapper. The importer validates the recognized wrapper and reads its data; it never executes the file as JavaScript. You do not need to run a script, load it into a console, or open the archive viewer to compare it.

Where a category is split across files, include its relevant supported parts in the same source. Keep collections in separate folders so an October part cannot accidentally join the September input. ZIP and HTML are not supported imports. A rejected file is a preparation issue to resolve, not evidence that the category contains zero accounts. Keep the original download intact while working with the extracted comparison files.

Treat archive accountId values and handles as different identities

The important field in a supported follower or following archive record is accountId. It contains a numeric account identifier, not an at sign username. For an illustrative record containing "accountId": "910700101", the checker produces id:910700101. The prefix makes the identity type explicit. An accompanying userLink is not a ready made handle, and the checker does not follow that link to discover a current username.

Suppose your earlier archive contains id:910700101 and your later manually prepared list contains @harborpress. Even if your own notes say they refer to the same account, the checker cannot establish that connection from these two strings. They remain different identifiers. A numeric archive compared with a handle list can therefore produce many apparent removals and additions that are really a representation mismatch.

Use account IDs on both sides for an archive comparison. Use handles or recognized handle based profile URLs on both sides for a prepared handle comparison. Do not turn an account ID into a handle by removing the prefix, and do not turn a handle into an ID by adding it. If you lack a trustworthy matching identity type, collect a compatible list rather than guessing a conversion.

X’s official documentation separates a user’s ID from their username and notes that usernames can change. Its Help Center also explains that changing a username does not change existing followers. That matters historically: one account can appear under two handles across collections. ID based comparisons avoid that particular spelling change, but they still do not prove an account is currently available or explain why it is missing from an archive.

Prepare compatible inputs and inspect the cleanup counts

For prepared text, paste one identifier per line. For CSV, choose the column that actually contains the handles or explicit IDs. For prepared JSON, use an array of identifier strings. Keep numeric IDs as text throughout preparation so a spreadsheet does not round a long value or replace it with scientific notation. A changed digit changes the identifier; formatting cannot recover the original value after precision has been lost.

Handle normalization removes a leading at sign, uses lowercase, and recognizes supported X or Twitter profile URL forms. Tracking attached to a recognized profile URL is not part of the canonical handle. These adjustments help equivalent representations match. They do not join a display name to a handle, resolve an old username, or verify the person behind an account. A lowercased string is still only a normalized input.

Inspect each source’s unique, duplicate, and invalid counts before comparing. Loading the same archive part twice should not double the distinct audience. Conversely, rejected candidates should not disappear from your reasoning just because the remaining rows parse successfully. When you remove an invalid line, document whether it was an unrelated heading, a damaged identifier, or an unsupported entry. That distinction helps explain any difference from the original file’s row count.

The input limits are 5 MB per file, 10 MB per source, and 100,000 candidate rows per source. Multiple supported files can share a source within those limits. A blank source is not a confirmed empty list: intentionally empty input must be marked explicitly. Never use that option to suppress a failed import. Fix the input and review the cleanup summary before treating its results as a usable baseline.

Work through a small following versus followers example

Imagine a coastal print studio reviewing a single archive. Its illustrative Following list contains six account IDs ending in 101, 102, 103, 104, 105, and 106, all with the shared prefix 910700. Its Followers list contains five IDs ending in 103, 104, 105, 107, and 108 with that same prefix. These are deliberately small fictional lists, using the same identity type on both sides.

The shared IDs end in 103, 104, and 105, so In both lists contains three entries. Following only contains the IDs ending in 101, 102, and 106, also three entries. Followers only contains the IDs ending in 107 and 108, giving two entries. The source totals reconcile: six following equals three shared plus three following only; five followers equals three shared plus two followers only.

Across the two sources there are eight distinct IDs, because the three shared entries count once in the union. The chart’s three disjoint buckets therefore total eight, not eleven. Adding six and five without subtracting the overlap would count each shared identifier twice. This is why a relationship chart should not be read as two separate audience totals stacked together, and why source counts remain useful alongside it.

The studio can describe the three A only entries as accounts it follows that are not in the supplied follower list. It cannot describe them as three historical unfollowers. Perhaps none ever followed the studio. For a comparison built from current prepared lists, use the same wording and retain the collection context. The followers versus following guide develops that relationship question separately from archive history.

Reconcile a larger archive snapshot comparison

Now give the print studio two follower collections, labeled September 3 and October 1. The earlier source has 742 candidate rows: 720 unique valid IDs, 16 duplicate occurrences, and six invalid candidates. The later source has 776 candidate rows: 755 unique valid IDs, 14 duplicate occurrences, and seven invalid candidates. Both cleanup calculations reconcile. Compare the validated unique IDs, while retaining the rejected entries for a separate preparation review.

Assume 681 valid IDs occur in both sources. The earlier only bucket is 720 minus 681, or 39 IDs absent from the later list. The later only bucket is 755 minus 681, or 74 added IDs. The three buckets total 794 distinct IDs across the comparison: 39 plus 74 plus 681. Neither duplicate occurrences nor invalid candidates belong in those three membership buckets.

The later validated list is larger by 35 IDs, since 755 minus 720 equals 35. The same net difference is 74 additions minus 39 absences. Reporting only that increase would hide the two different movements. Reporting 39 confirmed unfollows would add a claim the snapshots cannot establish. A useful summary includes the starting and ending unique counts, both difference buckets, the overlap, and the cleanup exceptions.

Optional dates identify the observations you supplied; they do not reveal the moment of a relationship change. Keep the archive request and download details in your own collection notes if the actual capture time is uncertain. In this example, the labels organize two files rather than prove an event interval. Incomplete collection, account changes, or other availability differences remain possibilities that the checker cannot distinguish from the identifiers alone.

Use results and exports without losing the comparison context

Select the bucket you need to inspect, then search within it. The list uses pages of 50 rows, while the displayed counts still describe the full comparison. Seeing only the first page does not mean the bucket contains only 50 identifiers. Search is a review aid, not a new calculation of the original source populations. Keep the full bucket total in any summary accompanying a short selection of examples.

Copy the selected list when you need its identifiers in a working note. Download CSV for the full categorized results, not merely the visible page. The PDF serves a different purpose: an aggregate report containing the chart, exact input and cleanup counts, optional dates, comparison context, and practical next steps. It does not include raw identifiers. Choose the export that matches the information your reviewer actually needs.

For the studio, send the PDF when the question is whether the two collections reconcile. Use the CSV when a colleague needs to examine the 39 absent IDs individually. Label both with the account, follower category, and ID based matching method. Do not rename an absent bucket Unfollowed customers, because the input establishes neither the action nor whether any identifier belongs to a customer. Preserve the measured category names.

Changing an input or rejecting an import invalidates the previous comparison’s exports. Correct the source and run the comparison again before distributing a replacement report. Results are displayed as text, not external profile links, and the checker does not fetch them. Any separate account review remains a separate task. Neither selecting a row nor exporting its ID checks a live profile or starts an unfollow action.

Build a repeatable archive review with a useful next step

Keep one collection folder per account and observation. Store the original archive separately from prepared comparison files, and record which category and parts you selected. Use an ID based series consistently when archives supply accountId values. If you start a handle based series instead, note that choice and its rename limitation. A repeatable identity convention contributes more to the next comparison than an elaborate report made from incompatible inputs.

Review surprising changes by checking preparation first: correct account, correct category, complete supported parts, same identity type, and plausible cleanup counts. If these checks reveal an incomplete source, repair the source and replace the result. If the source is sound but the cause remains unknown, leave the cause unknown. An unexplained absence is still useful as an observation when it is not dressed up as a verified action.

Choose the next task according to the business question. The Growth Health Checker can support a separate review using the metrics you enter, while the Social Media Profile Audit helps organize a profile review. Neither destination converts missing archive IDs into confirmed unfollows. Keep audience membership, content response, and commercial outcomes distinct instead of assuming one list difference explains all three.

SMTasker’s X automation workflows are separate from this free comparison. Supported X tasks include Like, Follow, Comment, Unfollow, and Repost, but the checker does not connect its output to those actions or import results automatically. Finish the evidence review first. Any later workflow decision should be based on your actual objective, not on treating a bucket of absent identifiers as a ready made action queue.

Questions about X follower comparisons

Continue with another list guide

Return to the Follower & Connection List Checker to compare your prepared data, explore a related guide below or browse all free tools.