What Is a User-Agent String?

A user-agent string is the value of the HTTP User-Agent request header that identifies the client software making a web request, often including the browser name and version, the rendering engine, and sometimes details about the operating system and device.

How a User-Agent String Works

Every HTTP request can include a User-Agent header. When your browser, script, or bot sends a request, it attaches a user-agent string so the server has a hint about what kind of client it is talking to.

Under the hood, the user agent value is set by the client software:

• Web browsers ship with a baked-in user-agent template.
• HTTP libraries (like python-requests, curl, or wget) expose a way to override it.
• Headless browsers and automation tools default to realistic browser UAs, but can also be customized.

A typical user-agent string looks like this:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

Servers read this header and may use it to:

• Adapt content (for example, mobile vs desktop layout).
• Log and segment traffic by device or browser.
• Gate access or trigger bot-detection checks.

Modern browsers are actively reducing how much information user-agent strings reveal because they are a passive fingerprinting surface. Chrome’s user-agent reduction rollout and the move toward User-Agent Client Hints (UA‑CH) mean that relying on raw UA parsing is discouraged, but the User-Agent header is still widely used in practice.

Why User-Agent Strings Matter for Residential Proxy Workloads

For teams running residential proxy workloads, the user-agent string is one of the most visible signals targets see, right next to your IP address. When you route traffic through residential IPs, your goal is usually to look like a normal user from that geography—not a generic script.

Three practical reasons user-agent strings matter in this context:

1. Consistency with IP geography
   If you’re scraping a European ecommerce site through a German residential IP, but your user-agent claims to be an outdated Android device or a niche browser, some anti-bot systems will flag the mismatch.

2. Avoiding default bot fingerprints
   Libraries like python-requests and curl send recognizable defaults such as:

   User-Agent: python-requests/2.31.0
   

   or

   User-Agent: curl/8.1.2
   

   These are fine for APIs but often suspicious for consumer-facing sites where almost all real users arrive via browsers.

3. Controlling noise in your data
   When user-agent and IP reputation collide with bot defenses, you may get CAPTCHAs, 302 loops, or blocked content instead of real pages. That pollution leads to noisy datasets and bad labels for AI systems. Imperva’s 2026 Bad Bot Report estimates that more than 53% of web traffic in 2025 was automated, so defenses are tuned to inspect signals like UA closely.

Pairing high-quality residential IPs with well-chosen, realistic user-agent strings lets you focus on measuring cost per successful result instead of fighting avoidable blocks. For a deeper, Python-focused treatment of this topic, see the related guide: Python user-agent headers: rotating identities with proxies to avoid noisy data.

Real vs Spoofed User-Agent Strings

A key property of user-agent strings is that they are client-controlled. That means they can be “real” or “spoofed”:

• Real user-agent string: The default value a browser or HTTP client sends, accurately describing itself. Example: a genuine Chrome UA emitted by a desktop browser.
• Spoofed user-agent string: Any UA value you override manually, whether to appear as a different browser, hide your library name, or run an experiment.

From the server’s perspective, there is no direct way to know whether a UA is real or spoofed. Detection is based on consistency across signals:

• Does the UA match what JavaScript feature detection sees?
• Does TLS behavior look like that browser family?
• Does the UA roughly match the OS implied by IP reputation and regional patterns?
• Does the UA family align with other headers and client hints?

Security and anti-bot systems use multiple signals—User-Agent, HTTP header ordering, TLS fingerprints, cookies, JavaScript APIs, and IP reputation—to decide if traffic is likely human or automated. MDN explicitly warns that UA sniffing alone is unreliable; modern systems combine it with feature detection and richer hints.

For residential proxy workloads, the goal is typically plausible realism, not perfect spoofing:

• Use a small, curated set of modern browser UAs (for example, current Chrome and Safari variants).
• Align UA families with device types you expect for that workflow (desktop vs mobile).
• Match UA distribution to the type of site: mobile-heavy for some apps, desktop-heavy for certain B2B tools.

Related Terms and How They Differ

User-agent strings are often confused with several neighboring concepts. They are related but not the same:

User-Agent String vs User-Agent Header

• User-Agent header: The HTTP header field itself (User-Agent: ...).
• User-agent string: The textual value placed in that header.

In practice engineers use the terms interchangeably, but it helps to remember that the string is just the value, while the header is the field carrying it.

User-Agent String vs User-Agent Client Hints (UA‑CH)

• User-agent string: A single, legacy-formatted header value, easy to spoof and historically very detailed.
• User-Agent Client Hints (UA‑CH): A newer mechanism where the browser sends high-level info by default and only returns more detailed fields when the server explicitly asks.

Chrome and MDN both recommend moving to UA‑CH for privacy and reliability, but most servers still examine the traditional UA string because it exists on every request.

User-Agent String vs IP Address (or Proxy)

• IP address / proxy: Network-level identity—where the request appears to originate from. Residential proxies like ProxyLane provide real consumer IPs with country, city, and ISP targeting.
• User-agent string: Application-level identity—what the client claims to be in terms of browser and device.

Bot defenses look at both. A realistic user-agent on a datacenter IP might still be scrutinized. Likewise, a consumer IP paired with a clearly automated UA may draw attention.

User-Agent String vs Fingerprint

• User-agent string: One field among many.
• Fingerprint: A composite profile of your client built from multiple signals (UA, client hints, fonts, canvas behavior, WebGL, screen size, timezone, etc.).

Rotating the UA string helps, but on sophisticated targets it is only one part of reducing how “bot-like” your crawler appears.

Example: Rotating User-Agents with ProxyLane IPs for an AI Evaluation Crawler

Consider a team running an AI evaluation crawler to measure how often product pages include certain schema markup. They run this crawler over a large ecommerce catalog using a pool of residential proxies to avoid overloading any one origin and to see region-specific content.

Their first attempt looks like this:

• All requests use a single residential exit IP at a time, rotating periodically.
• The crawler sends the library default UA: python-requests/2.31.0.
• Some sites start returning CAPTCHAs, and some responses are minimal or blocked, polluting the evaluation dataset.

They improve the setup in two steps:

1. Configure rotating residential IPs with sticky sessions where needed.

   • Independent, single-page checks use rotating sessions so each request appears from a fresh household IP.
   • Multi-step flows (login plus product browsing) use sticky sessions so the session looks like one user over time.

2. Introduce coordinated user-agent rotation.
   For every new session, the crawler assigns a UA from a curated list of current desktop browsers:

   import random
   import requests
   
   USER_AGENTS = [
       "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
       "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15",
       "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
   ]
   
   def make_request_through_proxy(session_id: str, url: str):
       ua = random.choice(USER_AGENTS)
       proxies = {
           "http": f"http://SESSION-{session_id}@proxy_host:proxy_port",
           "https": f"http://SESSION-{session_id}@proxy_host:proxy_port",
       }
       headers = {"User-Agent": ua}
       return requests.get(url, headers=headers, proxies=proxies, timeout=20)
   

   • Each session_id maps to a sticky residential IP.
   • Each session gets a realistic, modern UA.
   • UA rotation is slower than per-request IP rotation, mimicking how real users keep the same browser identity across multiple page loads.

In testing, this combination yields more stable responses and fewer blocks. The team measures a higher share of fully rendered product pages per gigabyte of traffic, improving both evaluation quality and costs.

The same pattern scales to larger crawls: rotate IPs through a residential provider with city/ISP targeting, rotate user-agents at a session level, and monitor which combinations deliver the best cost per validated result. When you are ready to try this with real residential traffic, you can plug these patterns directly into a provider like ProxyLane that supports rotating and sticky sessions over standard HTTP and SOCKS5 without a proprietary SDK.

ProxyLaneTraffic never expires

Premium residential proxies
From $2/GB

Scale your workflows with the tools you already use. Rotating or sticky sessions up to 72 hours.

Try 350 MB for $1.95 View plans