A profile page that says "Sorry, this page isn't available" is not the end of a username lookup. On Sep 5, 2026 we exported three OSINTsearch username runs, 547 rows for richard, 446 for meme and 329 for cia, and read the raw source payload on every row. Four rows carried a live ban or deletion flag: a Lolz.live account marked is_banned: true, a Kongregate account and a Grailed account marked banned: true, and an ActBlue page marked deleted: true. Every one of them still returned a numeric user ID, a profile URL and a scrape timestamp. Separately, in a public DOJ wire-fraud case, osintsearch.org pulled user ID 78250918300, a banned_or_disabled status, the bio text and the profile picture from an Instagram handle whose page is no longer available.
This post covers that leftover layer: what platforms do when they ban, suspend or delete, why the numeric ID beats the handle once that happens, what a ban flag is worth in different investigations, and how OSINT search tools expose it. OSINTsearch is the worked example because it normalizes account status into named export columns and keeps the raw payload per row; fingerprint.to gets credit where its extras carry the same flags.
What we looked at
Exports. OSINTsearch JSON exports (schema 2) for richard, meme and cia, run Sep 5, 2026 between 09:20 and 09:31 local time. fingerprint.to JSON exports for the same handles: richard from Aug 26, meme and cia from Sep 3. We searched every row's raw block (OSINTsearch) and extras block (fingerprint.to) for keys containing ban, delete, suspend or status.
Counting rule. A flag counts only when the platform returned a true boolean or an explicit banned role. banned: "no", is_banned: false and trade_ban_state: "None" are negative observations, useful because they show the platform answers the question, but not bans.
Case facts. The Daejon Love section uses only the facts in OSINTsearch's published write-up and the public DOJ filing it cites. Row counts are the tools' own profiles_found values, no dedupe, no rerun.
What actually happens after a ban, suspension or deletion
Users treat these as one event: the account is gone. Platforms treat them as three database states, and none is a full erase on day one.
Ban or suspension. The account row stays. The public route returns a placeholder (Instagram's "Instagram User" name, Twitter's suspended interstitial, a Steam trade-ban badge). Internal APIs, GraphQL and mobile endpoints often keep answering for the numeric ID. Some platforms expose the status on purpose: Steam publishes vac_banned and trade_ban_state, Lolz.live sets role: "banned", Kongregate and Grailed return a banned boolean.
User deletion. Most platforms soft-delete first. The row is flagged, the handle is held for a window that varies by service, and the CDN keeps serving the avatar at the old URL until the cache expires. ActBlue's response for the deleted cia page is the clean example: deleted: true, public: false, but page ID 850514, the page name and the title were all still returned.
Third-party mirrors. Wayback captures, search caches and name-tracking services (NameMC, R6 name history) keep their own copy regardless of what the origin does.
A 404 is one observation about one route on one day. It does not prove the account never existed or that it is gone from every endpoint.
Why a stable numeric user ID beats a handle
Handles are mutable and recyclable. IDs are neither, on nearly every platform that matters. When an Instagram account is disabled, the handle is eventually released and a new account can claim it. The pk (Instagram's numeric ID) is never reissued. The same holds for Steam's 17-digit steam_id64, Twitter's numeric ID, Roblox's user ID, Mastodon's per-instance account ID and Vinted's member ID. In the OSINTsearch richard export, 365 of 547 rows carried a user_id; meme 282 of 446; cia 221 of 329.
That number is what lets you say two records refer to the same account across time. The richard Instagram row returned pk: 50573360537 with date_joined: December 2021. If that handle is banned next month and re-registered, the new account gets a different pk. A retrieval before the ban and one after can be compared on the ID, not the name. That is the continuity argument in the DOJ example below, and it is why former usernames and name history matter: they tie old handles to the ID that survived.
The Daejon Love example: metadata from an unavailable Instagram profile
OSINTsearch published a worked case on Sep 5, 2026: Daejon Love Instagram: Metadata From an Unavailable Profile. The underlying matter is a public DOJ wire-fraud case in the District of Oregon. The defendants named are Daejon Love and Taylor Jamie Chan, and the government alleges about $1.3 million was obtained from more than two dozen women. These are charges, not findings. Neither defendant has been convicted of anything as far as the published record shows.
For the banned Instagram handle in that case, OSINTsearch's lookup returned:
- User ID 78250918300
- A
banned_or_disabledstatus flag - The bio text
- The profile picture
- The placeholder display name "Instagram User"
All from a page that returns unavailable in a browser. Three lines from the write-up are worth keeping:
"An unavailable page alone does not establish that an account never existed"
"Preserve the result with its retrieval date, source fields and any limits on the observation"
"A matching account ID can support continuity between records; it does not establish who operated the account or whether the allegations are true."
That is the frame for every banned account lookup. The ID supports continuity: two records point at the same account object. It says nothing about who was typing or whether the allegations hold. A suspended account lookup that produces an ID and a status flag has produced evidence of account state, not evidence of conduct.
What each platform exposes after a ban
Built from the flags in the Sep 5 OSINTsearch exports, the fingerprint.to exports for the same handles, and the Instagram case above. It lists what these sources returned, not every platform's policy.
| Platform | Key seen in export | What survives after ban or deletion | Seen on |
|---|---|---|---|
pk, date_joined, status (banned_or_disabled in the case write-up) |
Numeric ID, join month, bio, avatar, "Instagram User" placeholder | richard, cia (active rows); Daejon Love case (banned) | |
| Steam | steam_id64, vac_banned, trade_ban_state, name_history, former_names |
Permanent 64-bit ID, VAC and trade ban status, full name history with change dates | richard, meme, cia (all None and false) |
| Lolz.live | is_banned, role, style_class |
Member ID, banned role, market URL | richard (is_banned: true, role: "banned") |
| Kongregate | banned, level, points, badge_count |
Account ID, ban boolean, activity counters, join date | meme (banned: true), richard (false) |
| Grailed | banned, confirmed, marketplaces |
User ID, ban boolean, marketplace membership | meme (banned: true), cia (false) |
| ActBlue | deleted, public, page_id, entity_id |
Page ID, entity ID, page title, deleted and public flags | cia (deleted: true, public: false) |
| Vinted | is_banned (fingerprint.to extras), member_id, last_loged_on_ts (OSINTsearch raw) |
Member ID, last login timestamp, feedback counts; ban boolean on fingerprint.to only | richard (fingerprint.to is_banned: true) |
| Roblox | is_banned (fingerprint.to extras) |
Ban boolean | meme (fingerprint.to is_banned: true); no Roblox row in the OSINTsearch meme export |
| Minds, Aparat | banned: "no" |
Ban answered as a string, not a boolean | richard, meme, cia (all "no") |
| Medium, Misskey, patriots.win, Danbooru, e621, NexusMods, Hexbear, Lemmy, Kick, Weasyl | is_suspended, is_deleted, is_banned, banned, deleted |
Ban, suspension and deletion booleans on the user object | richard, meme, cia (all false on every row where the platform appears) |
Two notes. Our starting tallies (richard 2 raw.banned, meme 4, cia 2) counted every row where the banned key held a non-empty value; two of richard's, two of meme's and both of cia's are the string "no" from Minds and Aparat. The confirmed count is richard 1 (Lolz), meme 2 (Kongregate, Grailed), cia 0 bans and 1 deletion (ActBlue). And fingerprint.to found two bans OSINTsearch did not, Vinted on richard and Roblox on meme: OSINTsearch's Vinted row for richard has no ban key, and its meme export has no Roblox row. Both tools found Lolz on richard and Kongregate plus Grailed on meme.
The OSINTsearch fields and what they mean
OSINTsearch exports two shapes. The JSON export (schema 2) carries normalized top-level fields (platform, username, user_id, profile_url, created_at, scraped_at, former_usernames) plus a raw block with the source payload untouched. The CSV widens that to 88 columns, with the account-state columns present in every row whether or not the platform filled them.
| Field | Where | Meaning | Read it as |
|---|---|---|---|
account_status |
CSV column | Normalized state string (active, banned_or_disabled, suspended, deleted, or empty) | The tool's summary of the platform's answer |
account_status_reason |
CSV column | Why the status was set, where the source says | Context, not proof |
account_banned |
CSV column | Boolean, normalized from banned, is_banned, role: banned |
The platform said banned at scraped_at |
is_suspended |
CSV column | Boolean, normalized from suspension keys | Temporary or moderation state, may lift |
is_deleted |
CSV column | Boolean, normalized from deleted, is_deleted, account_deleted |
Soft-deleted; ID and some fields may persist |
vac_banned |
CSV column | Steam anti-cheat ban | Game-specific; not a conduct signal outside gaming |
trade_ban |
CSV column | Steam trade ban state (None, Probation, Banned) |
Marketplace restriction; often follows scam reports |
former_usernames |
Both | Earlier handles the source returned | Continuity across renames |
user_id |
Both | Platform-native ID | The key to carry across retrievals |
scraped_at |
Both | UTC timestamp of the observation | Your retrieval date; document it |
raw.banned, raw.is_banned |
JSON raw | The platform's original key, untouched | Check the type: boolean vs string "no" |
raw.trade_ban_state |
JSON raw | Steam's original string | "None" means no trade ban |
raw.deleted, raw.last_status_at |
JSON raw | Original deletion flag; Mastodon's last post date | ActBlue returned deleted: true with the page ID intact; an empty last_status_at is dormancy, not a ban |
The difference between the tools is where the flag lives. fingerprint.to keeps is_banned and is_suspended inside each row's extras, next to unrelated keys like band_followings and vip_status, with the key name varying by platform (banned, is_banned, shadow_banned, suspended, is_suspended, account_deleted). OSINTsearch's CSV promotes those into account_banned, is_suspended and is_deleted columns you can filter in a spreadsheet, and the JSON raw block keeps the original so you can audit the mapping. Of the exports we opened for this series, OSINTsearch's is the only one with a normalized account-status column set; fingerprint.to's extras were richer on these three handles, since it flagged two bans OSINTsearch missed. The full OSINTsearch review covers the rest of the schema.
Two caveats. In the JSON exports, the CSV-style columns are not present on rows; the state is only in raw. And a normalized account_banned: true is only as good as the mapping. Minds and Aparat answer "no" as a string, and a normalizer that tests for truthiness would flag both as banned. Check the raw block before a flag goes in a report.
For the record, Revealer's username search has no account-status column at all; it won the row count on richard in our 11-engine benchmark, but "which of these accounts is banned" is a filter OSINTsearch answers and Revealer does not.
What a ban flag means in different investigations
A ban is a platform's decision, made under its own terms of service, by a process you cannot see. That shapes what you can do with it.
Fraud and scam attribution. A Steam trade ban or a Grailed banned: true on a marketplace handle is a lead that the platform received complaints. Pair it with created_at and former_usernames. The flag does not say why.
Harassment and threat cases. The stable ID is the point. A harasser who is suspended, waits, and returns on a new handle is often still reachable through name history or a preserved platform ID. Use the pre-ban retrieval as the anchor and the post-ban lookup for continuity.
CSAM and child-safety tips. Do not investigate. Preserve what you already have (URL, ID, scraped_at, screenshot) and report to NCMEC's CyberTipline or your national equivalent. A ban flag means the platform already acted; it does not change the reporting obligation, and downloading further material to document it is itself a crime in most jurisdictions.
Brand impersonation. Impersonation accounts are banned and recreated in cycles. The pk from each takedown, the date_joined and the avatar hash let a brand team show a pattern across disposable handles instead of unrelated one-offs. Escalation forms accept IDs and prefer them.
Employee vetting. A ban flag from a username lookup is not a consumer report and none of these tools are consumer reporting agencies. Using account-status data from Revealer, OSINTsearch or fingerprint.to for an employment, housing, credit or insurance decision falls outside the Fair Credit Reporting Act and exposes the employer to liability.
Documenting an unavailable profile with retrieval dates
Banned-account evidence decays: the CDN cache expires, the handle is recycled, the endpoint is patched. What you record on the day is what you will have.
- Capture both routes. A screenshot of the unavailable page and the export that returned the ID and status flag, both timestamped.
scraped_atdates the flag; the screenshot dates the unavailability. - Record the source field. Which key the flag came from (
raw.is_bannedon Lolz,raw.bannedon Kongregate,trade_ban_stateon Steam). Different keys mean different things and a reviewer will ask. - Record the limits. An empty
last_status_aton a Mastodon instance means no posts, not a ban. A Steamtrade_ban_state: "None"is an affirmative negative. Say which it is. - Keep the raw payload. OSINTsearch's JSON keeps it per row. If your tool does not, save the API response yourself.
- Hash the avatar. Profile pictures outlive bans on the CDN for a while and can tie a banned account to a replacement. Store the file and its hash.
- Write the continuity claim narrowly. "Account ID 78250918300 returned status banned_or_disabled on 2026-09-05" is a fact. "The defendant's account was banned" is a conclusion the data does not support.
FAQ
Can you look up a deleted or banned Instagram account's user ID after it is gone? Sometimes. In the Daejon Love case OSINTsearch returned ID 78250918300, the status flag, bio and avatar after the public page went unavailable. This is not guaranteed and it decays. Retrieve early and record the date.
Does fingerprint.to expose ban flags too?
Yes. On the same three handles its extras carried is_banned: true for Vinted and Lolz (richard) and Grailed, Kongregate and Roblox (meme), plus is_suspended: true for Tiendanube and Bigo on richard and meme. It found two bans OSINTsearch did not. fingerprint.to keeps them in per-row extras with platform-specific key names; OSINTsearch adds normalized columns.
Can I use a ban flag from a username lookup in a hiring decision? No. These tools are not consumer reporting agencies and the data is not FCRA-compliant. Use account-status data for fraud, security and threat intelligence within your own scope.
How long do deleted-account traces last? It varies by platform and artifact. Handles are held for a window, CDN-cached avatars can outlast it, and numeric IDs are never reissued on the major platforms, so an ID recorded before deletion remains a valid continuity key even after nothing resolves for it.