> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# User-Agent and browser modes
> Choose a User-Agent or Local-run browser, and use Browse Mode or Local Extraction to handle permitted interactive steps.
Octoparse lets you configure the User-Agent and browser mode used by an applicable task. These settings affect how a page is requested and rendered. They do not guarantee access to a protected website.
## User-Agent options
A User-Agent is a browser header that tells a website which browser and device type is making a request. It can affect whether the site returns a desktop, mobile, or browser-specific version of a page.
In supported task settings, you can use the default User-Agent, add and name a custom User-Agent, or select a User-Agent from the available list. The list includes desktop and mobile options. For workflows that need variation, the settings can support scheduled User-Agent changes, changing User-Agent with an IP change, or changing it during a supported action retry.
Use a stable User-Agent for a login-required session unless you have tested a change. Switching an IP and User-Agent together may improve consistency for some tests, but it can also cause a site to invalidate an existing session.
## Browse Mode: interact while building a task
Browse Mode is the task editor's manual interaction mode. It lets you use the built-in browser like a regular browser before you finish building the workflow.
Use Browse Mode to:
* Sign in to a website you are authorized to access
* Close a Cookie banner or other page overlay
* Complete an applicable Cloudflare or CAPTCHA step manually
* Navigate to the page state you need before selecting fields and actions
After manual interaction, return to Select Mode to define the task workflow. Browse Mode is for task editing; it is not a Local-run browser choice.
## Handle login or verification during a Local run
If a login page, CAPTCHA, or Cloudflare check appears during a Local run that uses the **Built-in Browser**, open **Show Browser**, select **Pause**, complete the permitted manual step, then select **Resume**. This keeps the task under your control while you verify that the browser reaches the intended page before extraction continues.
Use this workflow only for Local Extraction. Cloud runs do not provide the same manual browser handoff. See [Local Extraction](/docs/en/platform/local-extraction) for when to run on your device, and [CAPTCHA handling](/docs/en/platform/captcha-handling) for supported verification paths.
## Choose a browser for a Local run
When you run a task locally, the browser choice determines the browser environment that loads the target page. It does not change your task workflow or data fields.
| Browser | What it uses | Choose it when | What it means for access |
| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Built-in Browser** | Octoparse's built-in browser environment | You need a baseline Local run | Start here. If the page is blocked, blank, or challenged, test one other browser before changing several settings. |
| **Chrome for Testing** | A clean Chrome browser with no usual browser profile | You need a clean, separate environment | It separates the task from existing sessions and profiles, but the target site can still challenge it. |
| **Local Browser** | Your selected Chrome or Edge profile with the Octoparse extension | The task needs your normal browser environment or local session | It may behave closer to normal browsing and improve compatibility with some sites. It does not guarantee access. |
Chrome for Testing does not use your usual Chrome or Edge profile. Local Browser opens the task in a separate browser window and uses the profile you select.
## How browser choice affects access
Websites can respond differently to a built-in browser, a clean Chrome profile, and your local browser profile. The difference may come from the browser environment, stored Cookies, login state, or the way the target site renders and checks the page.
Use the browser choice as a controlled test, not as a universal anti-blocking switch:
1. Start with the Built-in Browser and save a screenshot and sample output.
2. If the page is blank, blocked, or incomplete, test Chrome for Testing with the same task settings.
3. Test Local Browser only when the target needs your local browser environment or session.
4. Keep the option that returns the correct page and complete data in repeated small tests.
The first Local Browser setup may require a short browser restart so Octoparse can connect its extension. Later Local Browser runs open a separate task window and do not take over pages you already have open.
Start with the Built-in Browser. If it does not return the expected page, test Chrome for Testing before trying Local Browser. After changing browsers, compare the final page, screenshot, and several output rows.
## Safe test workflow
1. Record the baseline page, screenshot, and sample output.
2. Change either the User-Agent or Local-run browser—not both at once.
3. Reload a representative page and confirm its expected state.
4. Run a small sample and review several fields, not only the first row.
5. Keep the setting only if it improves a reproducible failure without breaking session continuity.
Do not describe browser settings as a way to bypass every anti-bot system. If the target rejects access, shows a challenge, or returns incomplete content after a controlled test, use [troubleshooting](/docs/en/platform/troubleshoot-access-and-blocking) and stop repeated attempts when they do not improve the result.