How we verify visa data.
Visa data is messy. Rules change without notice, the same destination can have three conflicting unofficial summaries online, and even authoritative-looking aggregators lag behind embassy announcements. Here's exactly where every piece of data on this site comes from.
Three tiers of data
We're transparent about where each entry comes from — not everything on this site carries equal weight, so we mark the entries that do.
Residence-permit exemptions — hand-sourced
UAE residence, US Green Card, valid US B1/B2 visa, Schengen residence, Schengen C-visa, UK BRP, and Canadian PR exemptions are compiled manually from official government sources, with the source URL linked next to every country entry.
✓ high confidence Consider these entries the most reliable on the site.
Automated verification — re-checked against gov sources
High-traffic passport → destination pairs get re-verified by an
automated pipeline that uses WebSearch to pull the current rule
from embassy pages, ministries of foreign affairs, and official
e-visa portals. The source URL must match our
domain-trust allowlist
(.gov, .gob, .gouv, mfa.*, etc.)
to be marked verified.
✓ medium–high confidence Marked with a ✓ on passport and destination pages.
Bulk matrix — community-maintained starting point
The bulk 199×199 visa matrix comes from the open-source Passport Index Dataset — an excellent community project that cross-references multiple sources. But: entries aren't individually sourced, so we treat this as a reasonable default, not a verified fact.
reasonable default No ✓ badge. Always verify with the destination embassy before booking.
How the verifier works
- Query. For each passport → destination pair, we ask Claude
(via the
claudeCLI) to research the current tourist-visa requirement using its WebSearch + WebFetch tools. - Constrain. The prompt explicitly limits the model to official government sources and asks for a structured JSON with status, day-limit, source URL, notes, and self-assessed confidence.
- Gate. The returned source URL is matched against a
hard-coded allowlist of government-domain patterns. A legitimate
source passes (e.g.
mofa.go.jp,travel.state.gov,canada.ca). An unofficial one (blog, aggregator) is downgraded to "low" confidence and the ✓ badge is withheld. - Persist. Each entry is written immediately to
verified-visas.json— so partial runs are safe to resume. - Display. On every passport and destination page, we check for a verified entry first. If present, we use the verified status (re-bucketing the country into the right section) and show the ✓ badge + source link.
What we don't do
- We don't cite travel-blog posts, airline fare-sites, or commercial visa aggregators (iVisa, PassportIndex.com, etc.) as authoritative.
- We don't guess. If the model can't find an official source, the entry is marked "unknown" and hidden from the site.
- We don't inflate confidence. The model's self-assessed confidence can only be downgraded by our domain gate, never upgraded.
- We don't claim to cover work/student/transit rules. Everything here is tourist / short-stay only.
- We don't pretend our data is live. It's a snapshot — refreshed on-demand by running the verifier.
Frequently asked questions
Why do some entries have a ✓ and some don't?
How do you decide what counts as an "official" source?
.gov, .gov.<cc> (like .gov.uk, .gov.au), .gob.<cc> (Spanish-speaking), .gouv.fr, .go.jp/kr/th/id, embassy/consulate subdomains, MFA subdomains (mfa.*, mofa.*, esteri.it, etc.), official visa portals (evisa.*, travel.state.gov, canada.ca, u.ae), EU official (europa.eu). A source URL must match one of these patterns to qualify.