Overview Live simulation Where it fits Why RTO Next steps
🎛️ Web page to browser tab control

Control a browser tab from your own web page

RTO lets a trusted admin page, support panel or internal app open and supervise a separate real browser tab — visibly, locally and only on explicitly allowed hosts.

Watch the live simulation Start with the SDK See examples

🧭 Your page is the console

The source page stays the human-facing control surface: buttons, status, logs and operator decisions remain understandable.

👁️ The target is visible

RTO controls real browser tabs the user can see. It does not turn the browser into a hidden black box.

🛡️ The boundary is explicit

Cross-domain control is bounded by allow-listed hosts. A page should not silently gain power over arbitrary websites.

🎬 Live simulation

See the control model before installing anything

Launch a browser-based simulation of the RTO experience: master page, visible controlled tabs, warning bar, security overlay and a result returned to the master tab.

No plugin install is required for this demo. It shows what users see when RTO is active.

Launch the live simulation

What the simulation makes clear

  • The web page can act as a master control panel.
  • The controlled tab opens visibly and stays identifiable.
  • The warning bar and overlay show when RTO is active.
  • The master page can receive a result from a controlled tab.
🚀 Try it now

Try a trusted page controlling one real tab

Minimal connection

The smallest useful proof for an admin page, support panel or internal tool: detect RTO, open a controlled tab, keep a tabKey, and confirm the bridge is working.

Try the minimal demo Browse all examples

The basic flow

Trusted page Local RTO bridge Visible tab
✅ Where this fits

Use RTO when your web page is the controller and the tab stays part of the visible workflow

A strong fit

  • Your source page needs to trigger tab actions from a normal browser UI.
  • The destination host is trusted and can be explicitly allow-listed.
  • You want the target tab to remain visible and debuggable.
  • You prefer a local browser extension bridge over a backend relay service.

How to explain it to an evaluator

One trusted page coordinates another real browser tab locally. The workflow stays visible, bounded and easier to inspect than a hidden automation stack.

RTO is strongest when the operator should understand what is happening, not just receive a mysterious “done” signal.

💡 Why RTO

Three reasons teams choose this approach

🏢 Admin page friendly

Your own page becomes the controller without replacing the browser with a hidden automation layer.

🛡️ Cross-domain, but bounded

Allowed cross-domain control is explicit, user-visible and deny-by-default.

🔑 Clear targeting

Use tabKey or tabId to keep multi-tab workflows understandable.

🧩 Next steps

Move from guide to first working flow

SDK

Start fast with the browser-side SDK.

Open SDK

Docs

Read the public contract and allow-list notes.

Open docs

Compare

See where RTO fits against other stacks.

Open compare

Simulation

Watch the full visible-tab workflow.

Watch demo
Browser guide Chrome guide Firefox guide