Geoceptor vs GeoSpoof: A Signal-by-Signal Comparison | GeoSpoof BlogSkip to main content<br>Download<br>Geoceptor and GeoSpoof both change your browser's reported location, but on a full fingerprint test GeoSpoof keeps every signal consistent while Geoceptor leaks several. In our runs Geoceptor exposed the real IP through WebRTC, ignored historical timezone offsets, returned wrong values from Date.getHours/setHours and the Date string methods, and failed on blob-URL, data-URL, and nested workers. GeoSpoof passed all of those. Both handled Intl formatting correctly.

Changing the location a website sees is the easy part. Any extension can set<br>navigator.geolocation to coordinates in Paris. The hard part is making every<br>other signal agree, because a site that catches one disagreement doesn't see<br>Paris — it sees someone pretending to be in Paris, which is worse than not<br>hiding at all.

So instead of comparing feature lists, we put Geoceptor<br>and GeoSpoof through the same test: our own<br>browser location test page, which probes the full stack of signals a<br>real fingerprinting script would check. Same browser, same target location, same<br>seven checks. Every screenshot below is a live result.

How the test works

The verify page doesn't just read back the location you set. It pulls<br>each signal independently — WebRTC, the timezone offset, individual Date<br>methods, locale formatting, and a set of exotic execution contexts — then checks<br>whether they tell the same story. A green result means the signals are<br>internally consistent. A red one means a site could spot the contradiction.

If you want to follow along, install either extension, set a location, and open<br>the test yourself. Nothing here is hand-picked; it's just what the page returns.

1. The overview

First, the top-level verdict with each extension active and spoofing to the same<br>location.

GeoSpoofGeoceptorGeoSpoof comes back clean; Geoceptor leaves several signals exposed.<br>Geoceptor moves the location, but the summary flags exposed signals across<br>WebRTC, the timezone offsets, Date components, date and time strings, and the<br>advanced surfaces. GeoSpoof reports a clean, consistent result. The rest of the<br>post is just walking through why — one signal at a time.

2. WebRTC

WebRTC is the leak that bypasses VPNs, and<br>it's the one that matters most: it can hand a site your real public IP directly,<br>regardless of what your geolocation says.

GeoSpoofGeoceptorGeoSpoof patches WebRTC; Geoceptor doesn't protect it.<br>Geoceptor leaves WebRTC untouched, so the real IP surfaces. A spoofed<br>geolocation pointing at one country while WebRTC quietly reports an IP in another<br>is exactly the kind of contradiction fingerprinting systems live for. GeoSpoof<br>closes the surface so there's nothing to cross-check against.

3. Timezone and offsets

Setting the timezone name is easy. The trap is the offset , and<br>specifically historical offsets — the UTC offset for a zone isn't constant,<br>because daylight saving rules have changed over the years. A correct spoof has to<br>return the right offset for any date, not just today.

GeoSpoofGeoceptorGeoSpoof gets every date right; Geoceptor sets the zone but mishandles historical offsets.<br>Geoceptor changes the timezone correctly for the present, but doesn't account<br>for historical offsets, so a Date constructed for a past year reports an offset<br>that doesn't match the zone it claims. GeoSpoof computes the offset from the<br>zone's full history, so it stays consistent no matter which date a script picks.

4. Date components

Scripts can read the clock through individual Date methods like getHours()<br>and write to it with setHours(). These have to reflect the spoofed timezone,<br>and they have to round-trip correctly.

GeoSpoofGeoceptorGeoSpoof is correct; Geoceptor returns wrong values from getHours/setHours.<br>Here Geoceptor gets getHours and setHours wrong — the local-time components<br>don't line up with the timezone it's presenting, and the setter doesn't behave<br>consistently with the getter. GeoSpoof returns the correct values for both.

5. Date and time strings

The Date object also stringifies itself, and those strings embed the timezone<br>name and offset in plain text. toString(), toTimeString(), and<br>toLocaleTimeString() all have to agree with everything above.

GeoSpoofGeoceptorGeoSpoof's Date string methods match the spoofed zone; Geoceptor's disagree.<br>Geoceptor returns the wrong Date.toString, Date.toTimeString, and<br>Date.toLocaleTimeString — the strings still carry traces of the real timezone.<br>A script doesn't even have to call a special API for this; it just formats a date<br>and reads the offset out of the text. GeoSpoof gets all three right.

6. Intl formatting

Credit where it's due. The Intl API is another way to read the locale and<br>timezone, and this is the one check both extensions pass.

GeoSpoofGeoceptorBoth handle Intl formatting correctly.<br>Both Geoceptor and GeoSpoof return correct Intl formatting. If Intl were the<br>only signal a site checked, either extension would...