Metadata OSINT Toolkit — A local evidence workspace
A local application for inspecting photographs, testing location candidates and checking public sources. Original files, source records and uncertainty stay attached to the findings.
Explore the evidenceTimeline
2026
Role
Developer
3
Research cases
4
Export formats
SHA-256
Originals preserved
Engineering outcome
Original source → documented finding → portable report
Honest impact
An inspectable local research workflow demonstrated on public material. The examples show evidence and limitations; they do not establish a general accuracy rate or a forensic verdict.
Local OSINT · Engineering case
From a file to a finding you can inspect.
A local investigation workspace for photographs, location candidates and public sources. The useful output is a reviewable trail: what was observed, where it came from and what remains uncertain.
Local captures · 22 October 2026Inside the toolkit
The evidence, at working size.
Real application captures from three research scenarios, including an inconclusive provider failure. Open a view to inspect the full image.
Source collection
Public source material retained with its acquisition context. The Brandenburg Gate original was checked against its saved SHA-256 hash.
Three research scenarios · 22 October 2026
Different questions. Explicit evidence.
01 / Photograph with GPS
What does the original file actually say?
A public Brandenburg Gate photograph by AleWi, dated 12 March 2026, was imported from Wikimedia Commons. ExifTool read Pixel 7 Pro metadata and explicit GPS; the saved original passed the SHA-256 check.
Recorded outcome
Declared GPS: 52.516375, 13.3792694444. Berlin.de’s landmark point (52.5159, 13.378) is approximately 101 m away. Both are recorded separately in the report.
The file coordinates are not independently proven camera coordinates. Wikidata Q82425 was found; the Commons adapter returned HTTP 403, which was retained as a blocked source check.
Open the actual HTML report02 / Photograph without GPS
What happens when the provider cannot answer?
On 22 October, two new blind frames were submitted without EXIF, original filenames or location hints. The first returned HTTP 503; one explicit manual retry also returned 503. The second timed out on its first attempt.
Recorded outcome
Not evaluable for accuracy: 2 frames, 3 attempts, 0 semantic outputs. The failure records and actual image preview are preserved.
These are technical failures, not model abstentions. Small blind checks on 17 October included correct names, a wrong branch, an unknown result and, in a later pair, a correct address and an abstention. Those historical outcomes do not establish overall accuracy.
Open the actual HTML report03 / Public entity & domain
Can another person retrace the source check?
A public-source check of wikimedia.org combined DNS and RDAP responses with a Wikidata entity lookup. Source responses were kept alongside the interpreted findings.
Recorded outcome
2 MX records, 3 name servers and 1 RDAP response. Exact entity Q180 found; the name search returned 3 candidates, with Q180 ranked first.
The records document public technical observations at retrieval time. They do not independently establish legal ownership, control of an organisation or a person’s identity.
Open the actual HTML reportCaptures and original reports retain the app’s Russian interface. Two investigations completed; the visual scenario recorded provider unavailability. These are three research scenarios, not three successful geolocations.
Deliberately compact
One local application. A visible evidence trail.
Python and FastAPI coordinate the work; SQLite stores the case records, ExifTool reads metadata and Leaflet provides map context. External source checks depend on the selected public services.
Preserve the source
Keep the original file, its SHA-256 hash and the acquisition context.
Inspect locally
Extract file observations and store the investigation state in SQLite.
Review the finding
Keep confirmed observations, candidates and unknowns distinct.
Hand over evidence
Export reports and geographic data with source references and limitations.
Problem
Metadata, map results and public records are easy to collect separately. The harder task is keeping the original source, the reasoning and the limits together so another person can review a conclusion.
The Challenge
Connect file analysis, visual location research and public entity checks in one compact local application, without treating a search match as proof or an approximate location as the camera position.
The Solution
I built a Python/FastAPI application with SQLite, ExifTool and Leaflet. It preserves original files with SHA-256 hashes, separates observations from candidates, and produces reviewable reports and geographic exports.
Technical Highlights
Original files retained with SHA-256 hashes and source context.
ExifTool observations alongside maps and explicit location-candidate statuses.
Visual location research can return an unknown result instead of forcing a match.
Public entity and domain checks with source provenance.
Self-contained HTML reports and structured geographic exports.
A compact Python/FastAPI and SQLite application, with no cloud service required for local file analysis.
System Architecture
Python · FastAPI
SQLite · versioned migrations
ExifTool · Pillow · HEIC previews
Leaflet · OpenStreetMap
Gemini · visual hypotheses
HTML · JSON · GeoJSON · KML
Core Technologies
Related Projects
Have a process that should run as a safe AI system?
I turn complex workflows into a scoped pilot with typed tools, approval gates and verifiable outcomes. You work directly with the engineer who builds and deploys it.