NearScrub

2026-09-13

eBird and iNaturalist blur the map for at-risk species — your photo file still has the exact GPS coordinates

Since October 2017, eBird — the Cornell Lab of Ornithology's citizen-science checklist platform — has hidden the exact coordinates of sightings for 325 at-risk species behind shaded 20×20 km map blocks instead of a precise pin. eBird project leader Marshall Iliff explained why in comments Audubon later published: "the Asian-songbird crisis and similar poaching for the cage bird trade... made it very evident" that some locations needed protecting from the app's own users. iNaturalist runs a parallel system called geoprivacy: for any observation of a species flagged as threatened by "poaching, collection, persecution, or over-observing," it automatically swaps the true coordinates for a random point inside a roughly 0.2°×0.2° box — about 500 square kilometers — so the public map shows a plausible neighborhood, not a doorstep. Both systems work. Neither one touches the actual file.

What "obscured" changes, and what it can't reach

eBird's blocks and iNaturalist's geoprivacy are database settings on the observation record — the row that says which species, when, and (now) a fuzzed location. They govern what the platform's own maps, exports, and API responses show to someone browsing the site. They say nothing about the JPEG file itself, because by the time a photo reaches either platform's obscuring logic, the file has already existed for as long as it took to walk from the camera to an upload form — sitting on a phone, a memory card, a laptop folder, a cloud backup — with its EXIF GPS tag already written at the moment of capture, before either app ever saw it. Obscuring changes what eBird or iNaturalist choose to display about a sighting. It was never designed to, and doesn't, reach into a file's own metadata and rewrite it.

The guidance that gives this away

The tell that this gap is real, and known, is that the same conservation organizations running these systems separately tell photographers to handle the file themselves. Audubon's own "Dos and Don'ts of Nest Photography" instructs photographers, before sharing an image of a threatened or endangered species' nest, to "remove all GPS-embedded data from the image" — full stop, not "check that the app obscured it." A separate Audubon piece, "Tips for Being a Responsible Bird Photographer in the Social Media Age," lays out three places to intervene: disabling geotagging so the data is "never captured" in the first place, "wiping EXIF data from a photo you've shot," or "using apps that strip out sensitive details when you're sharing a photo" — and adds the detail that platforms vary, noting Flickr "preserves EXIF data by default" even where others don't. Archaeology Southwest, a heritage-preservation nonprofit working on a completely different kind of sensitive-location problem — looting, not poaching — gives essentially identical advice for site photos: "Remember that GPS coordinates may be embedded in your digital photos," so remove them before posting. Three organizations, two different things people are trying to protect, and the same two-step answer: let the platform obscure what it shows, and clear the file yourself, because those are different jobs.

A file outlives any one upload

The reason the file-level step matters isn't hypothetical. A photo taken to document a sighting for an eBird checklist doesn't necessarily stay a photo attached to that one checklist. The same file gets posted to a regional Facebook birding group for an ID discussion, forwarded to a listserv running a rare-bird alert, submitted to a photography contest, dropped into a blog post, or simply kept in a camera-roll backup that later gets shared for some unrelated reason. eBird's 20×20 km block and iNaturalist's geoprivacy box apply to what those two platforms display about that specific observation — not to the file, and not to any of the other places a copy of it might end up. Every one of those other destinations sees whatever the file itself still carries, independent of whatever setting was chosen back on the original upload.

Two layers, two different things they protect The platform layer eBird: 20×20 km shaded block iNaturalist: ~500 sq km geoprivacy box Controls what THAT platform's map, exports, and API show to visitors. Set once, per observation, in the app — never touches the photo file. The file layer The JPEG's own EXIF GPS tag — written by the camera at capture, before any app exists to obscure it. Present in every copy of the file — Facebook group, listserv, blog post, camera-roll backup — regardless of the platform setting on upload #1. NearScrub removes the file-layer GPS tag from JPEG/PNG exports, in the browser, before any of that.
eBird's map blocks and iNaturalist's geoprivacy box protect the observation record on one platform. The camera's own GPS tag, sitting in the file, is a separate thing that travels with every copy — which is why Audubon and Archaeology Southwest both tell photographers to clear it themselves.

Where NearScrub fits, and the two places it doesn't reach

This is exactly the file-layer step NearScrub is built to do: drop in an exported JPEG or PNG and the EXIF block — GPS coordinates included — comes out along with XMP and IPTC data, entirely in the browser, before the file goes to eBird, a Facebook group, or anywhere else. Pixel data is untouched; it's a metadata removal, not a re-edit of the photo. Two honest limits apply. First, NearScrub works on JPEG and PNG files — the exported, shareable copies most people actually post — not on RAW camera files. A wildlife photographer shooting Canon CR2/CR3, Nikon NEF, or Sony ARW for later processing has a GPS tag sitting in that RAW file the moment it's written, and NearScrub doesn't open RAW containers; the tag only comes out once that image is exported to JPEG or PNG and run through the scrubber. Second, NearScrub only ever touches the file sitting in your browser tab — it has no way to reach eBird's or iNaturalist's servers, and no opinion on how you set an observation's own location field in either app. That setting and the file's own metadata are two separate protections, covering two separate things, and neither one substitutes for the other.