One OSINTsearch investigation export we ran on 2026-09-07 came out as a 30-page PDF, split into 4 sections, covering 1 People Search source record, 2 included social profiles and 3 search runs that together logged 441 reported checks. The same case exported as a JSON file with 5 top-level keys and a CSV with an 88-column profile table plus appended case sections. That is the case-file format OSINTsearch ships, and its pricing page says every account including Free can export it. It is the first OSINT investigation report we have opened from a username search engine. This post maps it and compares it with the exports from Revealer.US, fingerprint.to and osint.industries. If you need an OSINT report template, the structure below is a good one to copy.
The engine itself is reviewed in the OSINTsearch review. This post is only about the exports.
What we looked at
A real investigation, exported three ways on 2026-09-07. PDF, JSON and CSV of one case: a People Search record, two email searches and one phone search pivoted from it. It contains a real person's name, addresses, phone numbers and emails, so this post describes structure only: page counts, section names, field names, the counts printed on the overview page and the caution wording. No value from the record appears here.
A synthetic fixture, exported 2026-09-06. OSINTsearch ships a demonstration case named Alexandria Bennett. Every address is on the reserved example.test domain and every phone number sits in the fictional 305-555 block, so its rows are safe to quote and are labeled synthetic below.
Standard username exports from 2026-09-05 (davidbombal, srhoe, richard) and competitor exports from Revealer (davidbombal, 2026-09-05), fingerprint.to (davidbombal, 2026-09-05) and osint.industries (richard, 2026-08-26), read for top-level structure only. We did not test the AI summary; the real export is stamped "EVIDENCE-ONLY EDITION".
The 30-page OSINTsearch case file, section by section
The cover carries "SUBJECT / INVESTIGATION", the case title, three counters (SOURCE PEOPLE, INCLUDED PROFILES, SEARCH RUNS), a SNAPSHOT timestamp in UTC, the edition stamp and a REPORT REFERENCE: a 12-character hexadecimal code repeated in every footer as "SOURCE-REPORTED EVIDENCE / reference / 02 OF 30".
| Section | Pages | What it holds |
|---|---|---|
| 01 Report overview | 1 to 2 | Counters, reading guide, caution, table of contents |
| 02 People source records | 3 to 8 | The People Search record, field by field |
| 03 Social evidence | 9 to 11 | Each included profile with provenance and observations |
| 04 Search journal | 12 to 30 | Every run, every endpoint, every outcome |
01 Report overview. Page 2 prints INCLUDED PROFILES, SEARCH RUNS and REPORTED CHECKS, then "Evidence at a glance": "This report includes 1 People Search source record, 2 included social profiles and 3 search runs. Each source retains its reference, reported fields and available search context." Then the line that makes this an evidence file: "No AI summary is included in this edition. The following pages present the supplied evidence and source-reported observations." Then the caution: "A shared email, phone number or username is an investigative lead. It does not establish that records belong to the same person. Verify source claims and dates independently."
02 People source records. Six pages for one person, labeled P01 and split into IDENTITY (Name, Full name, Location, numbered Aliases), CURRENT ADDRESS AND PROPERTY, one PAST ADDRESS n AND PROPERTY block per prior address, PHONE NUMBERS, EMAIL ADDRESSES and SOURCE. Address fields: Street, City, State, ZIP code, County, a "Residence since" or "Address recorded" month and year, a "Property details" flag (Reported or Not reported), then where reported Bathrooms, Bedrooms, Estimated value, Property type, Last sale price, Last sale date, Lot square feet, Occupancy, Ownership, Property class, Interior square feet, Year built and an "Open source link". Each phone has Number, Type (Wireless, Landline or Voip) and Carrier. SOURCE closes with Source (People Search), Captured At and Disclosure.
03 Social evidence. Each profile gets a label (S01, S02) and a line "Evidence references: P01 R01" tying it to the person record and the run that produced it. Under that: PROFILE DETAILS (Platform, Platform Label, Username, Display Name, Verified, Email), EVIDENCE AND PROVENANCE (Source, Evidence source, Scraped At), ADDITIONAL ACCOUNT FACTS and an OBSERVATION R01 block with the fields as seen in that run. Source is a lineage string such as "People Search email: (address)" and Evidence source is cross_reference: the profile came from searching an identifier lifted from the People Search record.
04 Search journal. Nineteen pages. Each run (R01 to R03) lists subject, status, search type, Source Person, Started and Completed, Credit status, Duration (ms), Endpoints checked, Found, Not Found and Could Not Check, an Identity block, then a Platform / Outcome / Source detail table for every endpoint touched. Outcomes we saw: not found, rate limited and error, with HTTP codes and proxy messages preserved. The last page closes with "Source notes": "Reported values are retained as supplied. Missing property or account fields were not reported. A shared identifier does not establish that accounts belong to the same person."
The runs were two email searches (209 and 208 endpoints) and one phone search (24 endpoints). 209 plus 208 plus 24 is 441, the REPORTED CHECKS figure on page 2.
The JSON case file
The JSON export declares schema: investigation-1 and has five top-level keys. Here is the map, using the synthetic fixture for any values.
| Key | Contents |
|---|---|
meta |
tool, site, schema, exported_at, investigation_id (a UUID), title, created_at, updated_at, people, searches, profiles_found, note |
people[] |
id, source ("People Search"), captured_at, disclosure, record {info {name, full_name, age, location, current_address}, past_addresses[], phone_numbers[] {number, type, carrier}, emails[], aliases[]} |
platforms[] |
one row per included profile: platform, platform_label, username, display_name, profile_url, verified, followers, bio, location, email, source, source_kind, scraped_at, extras[], raw{}, result_key |
evidence[] |
key (platform::search_id), platform, username, search_ids[], source_entries[] {search_id, key}, source_person_ids[] |
searches[] |
id, subject, subject_type, source_person_id, status, started_at, completed_at, charge_status, results {meta, search, identity, platforms, errors[], not_found[]} |
meta.note carries the caution in its shorter form: "Search results are investigative leads. A shared identifier does not establish that accounts belong to the same person."
evidence[] is the join table. In the synthetic case the LinkedIn profile lists two search_ids because both runs returned it. Its platforms[] row records that as one source string (synthetic):
"source": "People Search email: [email protected] | People Search phone: +13055550100",
"source_kind": "cross_reference"
The GitHub row alexbennett carries only the email lineage; a second row alexbennett2 carries only the phone lineage, with the bio "Distinct account returned by this second cross-reference." Two pivots from one record can land on different accounts; the report keeps them apart.
Each searches[] entry embeds a full single-search result under results: its own meta (schema "3"), a search block (duration_ms, endpoints_scanned, endpoints_total, found, not_found, could_not_check), the identity block and the run's platforms, errors and not_found lists. One real email run carried 65 error entries and 143 not_found entries. Nothing that failed is dropped; it is filed under the run that failed.
The multi-section CSV
The CSV opens as a normal profile table, one row per included profile, 88 columns wide in the investigation export, from platform and username through account_status, account_banned, is_deleted, is_suspended and former_usernames to source, source_kind, seed_username, seed_depth, seed_kind, seed_evidence, masked, mask_level, scraped_at and extras. After a blank line it appends case sections, each under a quoted # header:
| Section | Columns |
|---|---|
# investigation |
key, value (id, created_at, updated_at, note) |
# people |
person_id, captured_at, disclosure, name, full_name, age, location, aliases |
# people_addresses |
person_id, kind (current or past), address_index, street, city, state, zip_code, county, since, recorded, property_details_status |
# people_property_details |
person_id, kind, address_index, field, value |
# people_contacts |
person_id, kind (phone or email), value, type, carrier |
# investigation_searches |
id, subject, subject_type, source_person_id, status, started_at, completed_at, error, charged_credits, charge_status |
# investigation_evidence |
result_key, platform, username, search_ids |
# search_results <search id> |
one per run, with # search, # identity, # errors and # not_found sub-blocks |
A synthetic # people_contacts row:
"25cab7fe-...","phone","3055550100","Landline","Fixture carrier"
One file a spreadsheet opens and a script can split on the # markers. The real export was 589 lines.
The standard username export
The investigation format wraps the ordinary search export. Our 2026-09-05 morning exports declared schema: 2 (meta, identity, platforms); by evening the file declared schema: 3 and added search, errors and not_found. The identity block uses the same key set in both, printed where a run has data for it: probable_name with value, confidence and per-platform sources, probable_location, probable_email, username_variants each with sources, websites, profile_pictures, profile_links, bio with its source, and platforms_agreeing. On davidbombal the probable name carried confidence 0.31 with 18 sources and four named alternatives. Every platform row has source (primary scan, bio_link or cross_reference), source_kind and scraped_at; the 88-column CSV adds seed_username, seed_depth, seed_kind, seed_evidence, masked and mask_level.
Export pricing from osintsearch.org/pricing on 2026-09-09: Free, $0, 15 searches a week, with "PDF, JSON and CSV exports of your available results" and evidence-only PDFs. Starter, $20 a month, 50 searches a week, full profiles and AI summaries in the PDF. Pro, $49.99, 500 a week, full breach records with identifiers and deep search depths 1 to 4. Enterprise is custom. The page states "Every account, including Free, can export JSON, CSV and PDF reports." Yearly billing saves up to 17%. Quotas reset Monday 00:00 UTC.
Why field-level provenance matters
A defensible OSINT investigation report answers four questions for every fact: where it came from, when it was observed, why it was searched, and how much of it was shown. OSINTsearch answers those with four fields per row.
source names the origin: "primary scan" (the user's query hit the platform), "bio_link" (followed from another profile's bio) or "cross_reference" (an identifier from a People Search record or a prior result was searched). In the investigation export the string also names the identifier, so the chain reads People Search record, to email, to email module, to profile.
scraped_at timestamps the observation per row. A profile that shows as banned today may not tomorrow. The OSINTsearch blog's Daejon Love write-up states the rule: "Preserve the result with its retrieval date, source fields and any limits on the observation."
seed_evidence and seed_depth say which upstream handle produced a deep-search row and how many hops out it sits. mask_level records whether a value is the full identifier or a masked recovery hint. A masked email is a lead to a mailbox pattern, not the mailbox.
None of this is chain of custody in the legal sense. Chain of custody OSINT practice records who handled the evidence, when, and whether it changed. The report reference, footers and per-row scraped_at cover "what and when". The "who" and the hash are on you: hash the files, store them with the reference code, note who ran the search.
How the other exports compare
Revealer.US (davidbombal, 2026-09-05, exportSchema: 2). Sixteen top-level keys: target, searchMode, exportedAt, exportSchema, toolVersion, sourcesChecked (813), elapsedMs, profileCount (57), mentionCount (2), socialProfiles, mentions, crossReferences, dataBreaches, stealerLogs, behindTheEmail, emailDiscoveredProfiles. A wider result set than the OSINTsearch file, because breaches and stealer logs ride along, but not a case file: no per-row source-kind string, no journal of failed endpoints, no PDF.
fingerprint.to (davidbombal, 2026-09-05). Four keys: title, generated_at, summary, data. The summary lists Query, Type, Exported rows (69), Available rows (69), Profiles exported (69), Platforms checked (759/759) and Deep search (off): the closest thing to run accounting in any competitor export. No people record, no journal, no PDF.
osint.industries (richard, 2026-08-26). A JSON array of 400 objects with no envelope. Each has module, schemaModule, data, front_schemas, spec_format, status, query, from ("User supplied username."), reliable_source, pretty_name, type, category, widgets and attributes. No checked total anywhere, so no hit rate, and no case-file layer.
| Export | Top-level shape | Run accounting | Per-row provenance | Case file / PDF in the export we opened |
|---|---|---|---|---|
| OSINTsearch investigation | meta, people, platforms, evidence, searches | Per run: scanned, total, found, not_found, could_not_check, errors | source, source_kind, scraped_at, seed fields, mask_level | Yes, 30-page PDF plus JSON and CSV |
| Revealer.US | 16 keys incl. socialProfiles, dataBreaches, stealerLogs | sourcesChecked, profileCount | per-profile source name | No |
| fingerprint.to | title, generated_at, summary, data | summary list, 759/759 | in extras | No |
| osint.industries | array of 400 module objects | none | from, reliable_source | No |
To be exact: neither Revealer, fingerprint.to nor osint.industries shipped a case-file PDF in the exports we opened. We did not test whether they generate one elsewhere.
Reading the report like an analyst
Start on page 2. The counters tell you how much of the file is evidence and how much is journal. Here, 19 of 30 pages are journal, which is normal: that is where the negatives live, and negatives are evidence too.
Read the People source record as a vendor's claim, not a finding. "Property details Not reported" means the vendor had nothing for that address, not that the property does not exist.
Follow the evidence references. Each S profile points at a P record and an R run. Open that run and check Found, Could Not Check and the Outcome for the module that produced the hit. A hit from a run with 65 could-not-check entries is thinner than one from a clean run.
Treat cross_reference rows as the report does. The lineage says an email or phone was searched and a platform answered. That means the identifier is registered there, not that the person in the P record operates the account. The report repeats this on page 2, on the last page and in meta.note because it is the most common analyst error.
The FCRA caveat and the not-a-background-check line
The People Search records in an OSINTsearch investigation are consumer data: name, aliases, address history, property valuations, phone carriers. That is the raw material of a background check, the category the Fair Credit Reporting Act regulates for employment, housing, credit or insurance decisions. OSINTsearch does not present itself as a consumer reporting agency, and its report says the opposite of what a background check says: shared identifiers are leads, and source claims and dates must be verified independently. For an eligibility decision about a person, use an FCRA-compliant provider. For an investigation, the caution is the correct standard. The same applies to Revealer's username search and breach lookup exports, which are not consumer reports either.
Frequently asked questions
What is in an OSINTsearch investigation report? Four PDF sections: report overview with counters and caution, People Search source records field by field, included social profiles with provenance, and a search journal of every endpoint and outcome. Our 2026-09-07 export ran to 30 pages for 1 person record, 2 profiles and 3 runs totaling 441 checks.
Can I export OSINT results to PDF on the free plan? As of 2026-09-09 the pricing page says every account, including Free, can export JSON, CSV and PDF, with Free PDFs limited to evidence only. AI summaries in the PDF start on Starter at $20 a month.
How does the OSINTsearch export compare with Revealer's? Revealer's JSON carries more result types, including breaches and stealer logs, and returned 57 profiles from 813 sources on davidbombal against OSINTsearch's 59 from 770 the same day. OSINTsearch's is the better case file; Revealer's is the better result snapshot.
Does a shared email or phone in the report prove it is the same person? No, and the report says so three times. A shared identifier is an investigative lead. It shows the identifier is registered on that platform, not who operates the account.
Can I use these reports for a background check? Not for employment, tenant, credit or insurance decisions. Neither OSINTsearch nor Revealer is a consumer reporting agency. Use an FCRA-compliant provider for those purposes.