Cursor IDE Browser Tools: A Production-Minded Review  

Cursor provides browser tooling that lets an LLM interact with real web pages and, more interestingly, lets you point at UI elements and find the corresponding code.

I spent some time experimenting with both features. This article is not a launch overview or a benchmark. It’s a practical, slightly opinionated walkthrough of what these tools actually feel like to use, where they help, and where they break down.

Cursor browser features in short

Cursor currently ships two separate browser‑related features:

1. Browser Controls (v1.7+): Built‑in browser MCP tools. The agent can open and control a Chromium browser using Chrome DevTools Protocol, either embedded in a Cursor tab or as a separate window.

2. Browser Layout and Style Editor (v2.2+): A browser webview inside Cursor with visual tools for selecting elements and editing CSS. Think “design‑mode DevTools”, wired directly into the agent and your codebase.

They solve different problems, and behave very differently in practice.

Feature 1: Browser Controls (MCP tools)

This is Cursor’s built‑in version of what many teams already do with Playwright MCP. You ask the agent to open a URL, click around, fill forms, extract data, or post content. It runs a real browser session, sees page content, and interacts with the UI.

How to enable broswer control in Cursor? 

Normally it's enabled by default.

To double-check: open Cursor Settings, Tools & MCP, Browser:

Browser Controls: use cases

Here are some use-cases of the broswer control: 

1. Quick one‑off automation

Describe your automation case in plain text and run agent to perform it in browser.

Example: "Post a short news item to leap.epam.com based on the following article…"

Useful when setting up Playwright feels like overkill.

2. Adaptive automated testing

Write test cases in plain text, ask agent to run them and produce a report.

AI agent is flexible to adapt to minor changes in UI, capable of generating comprehensive test reports, rather than just failing a test in case in case of detecting a minor mismatch.

3. Agentic debug loop

Start local web application development server in watch mode to rebuild if code changes, run Debug mode in Cursor, describe an issue, add @Browser  into context, request to fix.

Agent will perform analyze  → fix  → reproduce  loop itself until the issue is fixed.

4. Fixing implementation to match Figma design

I wanted this to work: provide Figma design to agent, show how its actual implementation looks in browser, ask it to fix implementation to precisely match the design.

In practice, it mostly doesn't produce the perfect match: LLM doesn't seem to see enough detail to catch small spacing or typography differences. Large layout mismatches are detectable; subtle design polish is not.

What worked well

• No setup. No separate MCP server, no browser extension.
• It’s AI‑driven and reasonably tolerant to vague instructions. You can describe intent instead of spelling out every step.

Trade-offs and limitations

• Functionally, it’s not very different from Playwright MCP.
• Compared to scripted automation, the agent‑driven approach is less deterministic: it tends to read page content, reason about next steps, and adapt on the fly. That’s convenient, but it also means less predictability than an explicit Playwright script.

My takeaway: convenient, but not revolutionary. The value is mostly that it’s already there.

Feature 2: Browser Layout and Style Editor

This is the interesting one. You open a browser inside Cursor, with a side panel that acts as a layout and style editor. It has two core tools:

• Select element
  You hover over elements on the page and click. The selected element is immediately referenced in the chat. This is faster and less annoying than right‑click → Inspect → copy selector.

• CSS Inspector (design mode)
  A visual CSS editor that feels closer to Figma than DevTools. You adjust margins, padding, alignment, colors, and similar properties by hovering and scrolling instead of typing style rules by hand.

From what I can tell (purely from observation), this is a wrapper around Chrome DevTools with extra visualization.

On React sites, it almost certainly pulls data from React DevTools as well: the agent instantly knows the React component name and props. You never type the component name yourself, yet Cursor immediately searches for it in the codebase.

I also tried it with Angular. I did not observe similar framework‑level assistance, but finding the corresponding component in code still worked quite well.

How to open the editor in Cursor?

In the editor tabs ribbon, click the rightmost ... → select Open Browser

Or (v2.3+): click Change Layout (gear icon) in the main window header → select Browser layout

How it looks like?

Layout and Style Editor: use cases

Here are use-cases of layout and style editor: 

1. Finding code by pointing at UI

This works surprisingly well.

Click a UI element on the page, ask “find this component”, and Cursor starts searching for the corresponding component. I tried this with both React and Angular, and it worked in both cases.

For large codebases, this alone is valuable.

2. Visual UI tweaks applied to code

For simple pages, this feels great. Change padding, alignment, or color visually, then click Apply to ask the agent to implement those changes in code. It finds the right file and updates the underlying components correctly.

CSS‑in‑JS is not a blocker either. Even though class names are generated and meaningless, agentic code search often finds the right component through props and structure.

Where the Layout and Style Editor breaks down

This is where the rough edges show. (The points below are based on my testing as of late January 2026. Cursor ships patches frequently, so things may change over time.)

Stability and correctness issues

• Glitchy UI
  • Right‑click menus in the CSS inspector sometimes disappear after a second.
  • Drag‑and‑drop reordering works only for very simple structures.
• Select element stops working when the browser is opened in a separate window.
• Crashes
  • Opening the browser in a separate window and then opening the browser console crashed Cursor for me.
  • After restart, Cursor crashed again on startup.
• No right‑click → DOM view like in normal DevTools.
• Clicking multiple elements floods the chat with element references. You have to manually clean it up before giving the agent a clear target.
• One concrete failure: I tried to reorder sidebar navigation items by dragging them. The visual move worked, but the agent couldn’t reliably find the corresponding menu structure in code.

UX and ergonomics limitations

Screen space is a real constraint. The IDE, chat, browser, and CSS inspector all compete for width. On a regular monitor, the page often becomes so narrow that responsive layouts switch to mobile mode. That makes layout work awkward, especially for desktop‑first designs.

Overall impression

Browser Controls feel like a built‑in Playwright MCP. That’s good, and mostly about convenience.

Layout and Style Editor is more ambitious. It’s also more fragile.

When it works, it feels genuinely new: point at a UI element, and the LLM already knows which React component you mean. That kind of context handoff is hard to replicate with existing tools. I’m not aware of another integrated solution that does this without external extensions or MCP servers. The closest I’ve seen is the MCP Pointer project, which requires a Chrome extension and extra setup, and I didn’t explore it deeply here.

At the same time, this feature is clearly not “daily driver ready” for complex production apps. Glitches, crashes, and ergonomic constraints add friction quickly.

Final verdict: good vector, genuinely interesting idea, and already useful in narrow scenarios. For now, it makes sense as a sporadic, targeted tool rather than something you keep open all day. When Cursor stabilizes it and improves the ergonomics, this could become a very strong part of the IDE.