Geolocation Screenshot API

Your website looks different depending on who's looking at it and where they are. A visitor in Frankfurt sees a GDPR cookie banner and prices in euros. Someone in Tokyo sees Japanese yen and no consent overlay. A user in São Paulo gets redirected to your Portuguese subdomain. You know this because you built it that way. But when was the last time you actually verified it?

Usually this means firing up a VPN, switching to, say, Germany, clearing cookies, reloading the page and taking a screenshot. Then switching to Japan and doing the same thing. Then Brazil. You go through it location by location. With three countries that's manageable, maybe even fine. But imagine you need to check twenty. Or do it every week after a deploy. The process doesn't scale, and at the end you have a folder of PNGs with no timestamps and no proof of where they were taken from.

A geolocation screenshot API replaces that whole routine with a single request. ScreenshotRun's geo parameters let you take a screenshot from a different country in one API call: GPS coordinates, timezone, and proxy routing combined. The page renders with the right locale, the right currency, the right consent banners. You get back a screenshot that proves what users actually saw. Below we'll cover each parameter, show working code for common scenarios, and be upfront about the limitations.

How geo-targeted screenshots work

Three parameters work together to simulate a complete visitor from any location. Each one handles a different layer of geo-targeting, and most sites check more than one.

The geolocation parameter emulates the browser's GPS coordinates. Sites that use the Geolocation API (stores with "find nearby" features, map-based services, delivery apps) respond to these coordinates. You pass latitude, longitude, and optionally accuracy in meters.

Timezone detection is a separate layer. The timezone parameter sets the browser's IANA timezone (like Europe/Berlin or Asia/Tokyo), and JavaScript's Intl.DateTimeFormat().resolvedOptions().timeZone returns this value. Sites use it to display local times, show "open now / closed" indicators, or detect region. Without it, a page rendered through a German proxy still reports UTC or your server's timezone to JavaScript. That's a mismatch some sites catch.

IP-based restrictions are what most geo-systems actually check. The proxy parameter routes the request through an HTTP proxy at a specific IP address. CDNs, paywalls, and geo-redirect logic look at the request's IP, not GPS coordinates. GPS tells the page where you are. The proxy tells the server where you're from. Most sites only check one. When you combine all three, the page sees a consistent visitor from that location. No mismatched signals.

curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&geolocation[latitude]=52.52&geolocation[longitude]=13.405&geolocation[accuracy]=100&timezone=Europe/Berlin&proxy=http://user:[email protected]:8080&response_type=json" \
  -H "Authorization: Bearer YOUR_API_KEY"

That request uses the geolocation screenshot API to capture example.com as a visitor in Berlin would see it. GPS says Berlin, timezone says Berlin, IP says Germany.

Each parameter on its own

You don't need all three for every use case. Sometimes coordinates alone are enough. Sometimes you only need the screenshot API timezone parameter. Pick what the target site actually checks.

Geolocation (GPS coordinates)

# Capture with GPS coordinates for Berlin
curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&geolocation[latitude]=52.52&geolocation[longitude]=13.405&response_type=json" \
  -H "Authorization: Bearer YOUR_API_KEY"

The browser grants the page access to these coordinates through the Geolocation API, same as if a real user clicked "Allow" on the location permission prompt. Store locators, delivery radius checks, and "show nearby" features respond to this. Sites that rely on IP-based geolocation instead of the browser API won't be affected by this parameter alone, so you'd need a proxy for those.

Timezone emulation

# Capture with Tokyo timezone
curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&timezone=Asia/Tokyo&response_type=json" \
  -H "Authorization: Bearer YOUR_API_KEY"

Sets the browser's timezone to any valid IANA timezone identifier. JavaScript code on the page sees this timezone when it calls new Date() or Intl.DateTimeFormat(). This matters for sites that display local event times, show "open now / closed" indicators, or adjust content based on the visitor's time of day. One detail that trips people up: the screenshot API timezone setting doesn't change the Accept-Language header. A page in Asia/Tokyo still gets en-US in Accept-Language unless you also set a custom headers parameter.

Proxy routing for geo-targeted screenshots

# Route through a US proxy
curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&proxy=http://user:[email protected]:8080&response_type=json" \
  -H "Authorization: Bearer YOUR_API_KEY"

Routes the entire request through your HTTP proxy. The target site sees the proxy's IP address, not ScreenshotRun's servers. This is what you need for geo-restricted content, IP-based pricing, CDN edge testing, and any site that redirects based on visitor country. You provide your own proxy. We don't include managed proxies. Services like Bright Data, Oxylabs, or SmartProxy sell residential and datacenter proxies with country-level targeting built into the proxy URL. We've seen most users go with Bright Data or Oxylabs for this, though SmartProxy works fine too.

Use cases that actually need geo screenshots

Most screenshots don't need a location. But when location matters, there's no clean workaround, and VPN-hopping gets old fast. Five scenarios where we see geo parameters used most.

Cookie banner compliance across EU countries

GDPR requirements vary between EU member states. France requires a reject button as prominent as the accept button. Germany requires that no tracking fires before consent. Spain's enforcement is different from Slovenia's. Only about 15% of cookie consent implementations are fully compliant across all EU member states. A geo-targeted screenshot from each country proves what your banner actually shows (or doesn't) in each jurisdiction. Run it monthly, store the evidence.

# Python — verify cookie banners in 5 EU countries
import requests

countries = {
    "Germany": {"lat": 52.52, "lng": 13.405, "tz": "Europe/Berlin", "proxy": "http://user:[email protected]:8080"},
    "France": {"lat": 48.856, "lng": 2.352, "tz": "Europe/Paris", "proxy": "http://user:[email protected]:8080"},
    "Spain": {"lat": 40.416, "lng": -3.703, "tz": "Europe/Madrid", "proxy": "http://user:[email protected]:8080"},
    "Netherlands": {"lat": 52.37, "lng": 4.895, "tz": "Europe/Amsterdam", "proxy": "http://user:[email protected]:8080"},
    "Italy": {"lat": 41.902, "lng": 12.496, "tz": "Europe/Rome", "proxy": "http://user:[email protected]:8080"},
}

for country, geo in countries.items():
    result = requests.get(
        "https://api.screenshotrun.com/v1/screenshots/capture",
        params={
            "url": "https://your-site.com",
            "geolocation[latitude]": geo["lat"],
            "geolocation[longitude]": geo["lng"],
            "timezone": geo["tz"],
            "proxy": geo["proxy"],
            "full_page": "false",
            "response_type": "json",
        },
        headers={"Authorization": "Bearer YOUR_API_KEY"},
    )
    print(f"{country}: {result.json()['data']['status']}")

See the full Python integration guide for more examples including error handling and batch workflows.

Localized pricing and currency verification

Stripe lets you set regional pricing: $49 in the US, £39 in the UK, €45 in Germany, ¥5,900 in Japan. But does the pricing page actually show the right numbers to visitors in each country? Geo-targeted screenshots from each region confirm it. We've seen a locale detection library that mapped Swiss IPs to Germany. Swiss visitors saw euro pricing instead of francs for three months before anyone noticed. CDN caching the US price for everyone, JavaScript price switchers breaking on specific currencies: these are the problems that unit tests don't catch.

Geo-redirect verification

Your root domain redirects example.com to example.de for German visitors and example.co.jp for Japanese visitors. After a deploy, you need proof it still works. Without geo screenshots, you're asking team members in different countries to check manually, or trusting the redirect rules you just pushed. A quick loop through 10 countries with the proxy parameter tells you in 30 seconds whether every redirect lands on the right domain.

Local SERP monitoring

Google search results change dramatically by location. "Italian restaurant" in Madison, Wisconsin shows completely different local pack results than the same query in Jacksonville, Florida. SEO agencies that track local rankings can screenshot Google from specific coordinates to verify what their clients' customers actually see. The geolocation parameter places the browser at exact GPS coordinates, which is more precise than city-level proxy targeting for local pack results.

Ad creative verification

You're running display ads in 8 countries. The agency says the right creative shows in each market. You'd like to verify that without logging into the ad platform and trusting their preview tool. A geo-targeted screenshot of your landing page (or a publisher's site) from each target country captures what real visitors see, including which ad variant loads. Beats VPN-hopping through 8 countries manually.

Combining geo-targeted screenshots with other features

Geo parameters get more useful when you stack them with other ScreenshotRun parameters. A few combinations that come up often.

Add cookie blocking to capture what visitors see before accepting any consent banner. This shows the actual consent UI, not the page after cookies are accepted. Or remove cookie banners entirely with block_cookies=true to compare the underlying page content across countries without consent overlays getting in the way.

Use full page mode with geo parameters to capture the entire scrollable page from a specific location. Useful when geo-targeted content appears below the fold: regional promotions, localized footer links, country-specific trust badges.

Pair with certified screenshots for compliance evidence. The SHA-256 hash proves the file wasn't modified after capture, and the timestamp proves when it was taken. For GDPR audits, that combination (geo-targeted screenshot + certification hash + timestamp) is exactly what compliance teams need to show regulators.

If geo-targeted content loads asynchronously, use wait_for_selector to ensure the localized elements render before capture. Currency switchers and localized product grids often load after the initial page paint.

Set a custom viewport to match common device sizes in each market. Mobile dominates in parts of Asia and Africa; a geo screenshot from Tokyo on a 375px viewport shows what most visitors actually experience.

For batch geo-screenshot jobs across many countries, use webhooks to receive results asynchronously instead of polling. Send 50 requests, do something else, get notified when each one is ready.

Add custom headers to set Accept-Language matching the target country. Timezone emulation doesn't change the language header, so French content that's served based on Accept-Language needs headers[Accept-Language]=fr-FR alongside the timezone and proxy settings.

Common coordinates for geo-targeted screenshots

Quick reference for the cities that come up most in geo-screenshot workflows. Copy the coordinates directly into your API requests.

Geolocation screenshot API reference

What geo-targeted screenshots don't solve

Geolocation emulation makes the browser report specific coordinates and timezone to JavaScript. It doesn't change the underlying network characteristics: latency, packet routing, or TCP fingerprinting. Sophisticated anti-fraud systems that analyze connection-level signals might detect the mismatch between a German proxy IP and a US-based server's network fingerprint. Residential proxies pass geo checks on about 95% of sites. Datacenter proxies fail on roughly a third of aggressive anti-bot systems.

We don't provide managed proxies. You bring your own from a proxy provider. This adds a step compared to screenshot APIs that include built-in country routing, but it also means you're not locked into our proxy network, our country list, or our per-screenshot proxy surcharge. You pick the provider, the proxy type (datacenter or residential), and the pricing model that fits your volume.

Accept-Language isn't set automatically. Adding timezone=Europe/Berlin doesn't make the browser send Accept-Language: de-DE. Sites that serve localized content based on the Accept-Language header need you to set it explicitly via the headers parameter. We could auto-set it, but that would override cases where you specifically want to test what a German-IP visitor with an English browser preference sees.

The short version

Three parameters, one API call. geolocation sets GPS coordinates for the browser's Geolocation API. timezone sets the IANA timezone for JavaScript. proxy routes the request through a country-specific IP. Combine them and the page sees a fully consistent visitor from that location.

Where this matters most: cookie banner compliance across EU countries, localized pricing and currency verification, geo-redirect testing after deploys, local SERP monitoring from specific coordinates, and ad creative verification across target markets. Anywhere you'd normally fire up a VPN and check manually, this does it in code.

Start with your pricing page and two countries. If the currency is wrong, you've found your first bug.