Claude's Browser Use Tool vs Computer Use

Two tools for driving a screen, built for different screens

Claude has had computer use for a while: screenshots in, coordinate clicks and keystrokes out, driving an entire desktop with no structural understanding of what's actually on screen. On 19 August 2026, the same day computer use reached general availability, Anthropic shipped a second, narrower tool alongside it: browser use (browser_toolset_20260801), scoped specifically to a browser viewport your application hosts, and built to read a page's structure rather than only its pixels.

They solve overlapping problems, drive a UI Claude can't otherwise reach, but the right one to reach for depends on whether the task lives inside a browser tab or needs the whole desktop.

What browser use actually is

Per Anthropic's browser use tool reference, it's a client toolset: your application runs the actual browser and executes the calls Claude requests, then returns results, the same client-side execution model as computer use and any custom tool. What's different is how Claude perceives the page. Alongside screenshots and coordinates, the toolset gives Claude a way to read the page's accessibility tree as structured text, act on specific elements by a reference tag rather than a coordinate guess, set form values directly, and manage multiple tabs, none of which computer use offers, since computer use has no concept of "the page" at all, only pixels on a screen.

One toolset entry expands to 31 member tools in total: 27 enabled by default, plus 4 optional ones you turn on explicitly.

The member tools, grouped by what they do

Members marked * are disabled by default and need an explicit configs entry to turn on.

Reading the page instead of guessing at pixels

The core mechanic that separates browser use from computer use is read_page. It returns the accessibility tree as tagged text, elements like:

link "Documentation" [ref_1]
link "Getting started" [ref_2]
textbox "Search docs" [ref_3]
button "Search" [ref_4]

Claude can then act on ref_3 directly, a RefTarget, instead of estimating where that search box sits on screen and clicking a coordinate that might be off if the layout shifted since the last screenshot. find does the same lookup by natural-language description rather than reading the whole tree, and get_page_text returns just the visible text, tuned for articles and documentation rather than interactive elements.

References are scoped to the current tab and go stale on navigation or a DOM change. A call against a stale reference returns a specific, actionable error: "Error: ref_3 is stale or not found on the current page. Re-read the page to get fresh references.", telling Claude exactly what to do next rather than failing silently.

The request and response loop

Like every client toolset, browser use runs as a loop your application drives, not something Claude executes directly:

1. You include {"type": "browser_toolset_20260801"} in the request's tools array, alongside the user's prompt.
2. Claude responds with one or more tool_use blocks, each carrying a member name, its input, and toolset_name: "browser".
3. Your application runs each call against the real browser it's hosting, in the order Claude issued them.
4. You return the outcomes as tool_result blocks, echoing toolset_name: "browser" on each.
5. Claude reads the results and continues, issuing further calls or a final answer.

A minimal Python handler that processes one turn's worth of calls, stopping cleanly at the first failure inside a batch, looks like this:

NOT_EXECUTED = "Not executed: an earlier action in this turn failed."

def process_tool_calls(response):
    tool_results = []
    failed = False
    for block in response.content:
        if block.type != "tool_use" or block.toolset_name != "browser":
            continue
        result = {"type": "tool_result", "tool_use_id": block.id, "toolset_name": "browser"}
        if failed:
            result["content"], result["is_error"] = NOT_EXECUTED, True
        else:
            try:
                result["content"] = handle_browser_action(block.name, block.input)
            except Exception as err:
                result["content"], result["is_error"] = f"Error: {err}", True
                failed = True
        tool_results.append(result)
    return tool_results

handle_browser_action is the part you write yourself, dispatching each member name to whatever browser automation library your application already uses to drive the real page.

Batch actions and how failures propagate

A single turn can bundle multiple member calls, click a box, type a query, press Enter, as a batch action. Claude Code runs them in order and stops at the first failure; every call after that point in the same batch gets is_error: true and the content "Not executed: an earlier action in this turn failed." rather than attempting to continue against a page state the earlier failure may have left inconsistent.

Tab state as its own content block

Every successful call can report tab state in a dedicated browser_state content block, a full inventory of open tabs (never a delta), plus optional state_changes for things like a new tab opening or a download completing. This block is never sent on an is_error: true result, and each field is capped, 4,096 characters per tab title or URL, 100 tabs and 200 state changes per block, which matters because Anthropic explicitly flags URLs and titles as a prompt-injection surface: sanitise them before they reach this block, the same caution the tool's own security guidance gives for page content generally.

Downloads get their own three-state lifecycle inside state_changes, download_started, download_completed and download_failed, each keyed to a download_id so a long-running download can be tracked across multiple tool results without Claude having to poll for it.

Model and platform support

Per the current reference, browser use works with claude-fable-5, claude-mythos-5, claude-opus-5, claude-sonnet-5 and claude-opus-4-8, on the Claude API and Google Cloud. It is explicitly not available on Claude Platform on AWS, Amazon Bedrock, or Microsoft Foundry as of this writing, worth checking again before building against one of those three if the tool matters to your architecture. It is Zero Data Retention eligible, with the standard exclusion for Covered Models, which is a genuinely better compliance position than Claude Managed Agents currently offers, where ZDR isn't available at all regardless of tool choice.

Where browser use and computer use actually differ

The practical rule: if the task is genuinely desktop-wide, driving a non-browser application, switching between windows, using the OS shell, computer use is still the tool for it. If the task lives entirely inside a browser tab, filling a form, scraping structured content, navigating a multi-page flow, browser use gets there with fewer, more reliable calls, because it isn't reduced to guessing coordinates from a screenshot for something a page's own DOM already exposes cleanly.

Security: the page is not trustworthy input

Anthropic's own guidance for this tool is blunt: treat all page content as untrusted input, the same caution that applies to any agent skill reading external content. Page titles, URLs and read-page output can all carry a prompt injection attempt, and Claude can follow instructions embedded in a page that conflict with what you actually asked it to do. The documented mitigations are practical rather than theoretical: run the browser in a dedicated, low-privilege container or VM with a fresh profile and no stored credentials, restrict which hosts it can reach at the network layer rather than relying on the tool alone, leave javascript_exec and file_upload off unless a task genuinely needs them, and require human confirmation before anything consequential, a purchase, an account change, sending a message on someone's behalf.

javascript_exec deserves particular caution beyond the default-off setting: code it runs executes with the page's full privileges, cookies, storage access and same-origin requests included, so Anthropic's guidance is to enable it only in sessions where no logged-in session or credential is at risk, and to log whatever code Claude emits through it.

A worked configuration example

Enabling file upload and a couple of otherwise-off diagnostic members, while leaving JavaScript execution off:

{
  "type": "browser_toolset_20260801",
  "configs": {
    "read_console": {"enabled": true},
    "file_upload": {"enabled": true},
    "left_mouse_down": {"enabled": false},
    "left_mouse_up": {"enabled": false},
    "hold_key": {"enabled": false}
  }
}

That combination suits a task that needs to diagnose console errors and complete a file-upload form, without granting the tool the ability to run arbitrary script against the page.

Troubleshooting

Claude keeps clicking the wrong spot after a page updates. Check whether it's relying on coordinates from a stale screenshot rather than reading the page fresh. A read_page or find call before acting gives it a current element reference instead, which stays correct until the next navigation or DOM change rather than drifting as the layout shifts.

A call fails with a stale-reference error. This is expected behaviour, not a bug: references are scoped to the tab and invalidate on navigation or a DOM change. Re-read the page to get current references rather than retrying the same one.

javascript_exec or file_upload calls return "not enabled in this environment." Both are off by default. Add an explicit configs entry enabling the member you need, and review the security guidance above before doing so, particularly for javascript_exec.

The tool isn't available at all on my platform. Confirm you're on the Claude API or Google Cloud. Browser use is not available on Claude Platform on AWS, Amazon Bedrock, or Microsoft Foundry as of this writing.

Where to go next

For how this compares to the model-consultation pattern on the same API, see the advisor tool on the Claude Messages API. For the built-in tools available specifically inside Claude Managed Agents sessions, including how their web tools differ from this one, see Claude Managed Agents explained and restricting Claude Managed Agents' web search and web fetch to specific domains. For the general security posture this tool's own guidance echoes, see the Agent Skills security guide. Browse the current catalogue at getclaudeskills.com/skills.