Which device does your User-Agent announce?

What the User-Agent tells a website

Browsers, apps and scripts all attach a User-Agent header to their requests: one line that names the software and version, plus the operating system, the rendering engine and often the device type. Sites use it to choose, among other things, between the mobile and desktop versions of a page.

A typical example, from Chrome running on Windows 11:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36

Why it matters for mobile and market checks

Sites protected by services such as DataDome, PerimeterX, Akamai or Cloudflare check the User-Agent early in their assessment of every visit. A default Python requests string, a long-outdated Chrome version or “curl/7.x” can trigger a block page before the real content loads, and your team ends up reviewing an error screen instead of the ad or listing it meant to check.

A home or mobile IP from a proxy won’t change that. If the tool still identifies itself as python-requests/2.31.0, the household IP and the script header contradict each other, and the header usually decides the outcome.

Setting the User-Agent in your team’s tools

Most automation tools let you choose it. If a developer maintains yours, these are the usual places:

• cURL: curl -A "Mozilla/5.0 ..." https://example.com
• Python requests: requests.get(url, headers={"User-Agent": "Mozilla/5.0 ..."})
• Puppeteer: await page.setUserAgent("Mozilla/5.0 ...")
• Playwright: browser.new_context(user_agent="Mozilla/5.0 ...")
• Scrapy: change USER_AGENT in settings.py

For a quick manual check, the device toolbar in Chrome’s developer tools emulates a phone and switches that tab’s User-Agent to match. Keep each User-Agent tied to one profile or proxy session instead of swapping it on every request, and update it when browsers release new versions. Public lists of current strings (Safari on iOS, Chrome on Android, Chrome on Windows) make that easy.

Why device and connection should agree

Sites compare the device a visit claims with the network it comes from. An iPhone running Safari on a Comcast home line is what a site sees from its own customers every day. The identical string coming from an AWS server is not, and the site is more likely to respond with a check than with the page.

For mobile ad verification, local market research and QA, combine a User-Agent from the device you are testing with residential or mobile proxies from us, so the site is more likely to serve the version its real customers get. Stay inside each site’s terms of service and your local laws.