Remote Tab Opener · Site docs: 7.13.0 · Install the extension, then reload to show installed version
Free local browser extension for real tab automation

Control real browser tabs from your own page scripts

Remote Tab Opener lets you control real browser tabs across allowed domains from your own page scripts, with named tab reuse, visible automation, and no server, proxy, cloud relay, or Selenium grid.

Free to install Free SDK + docs + examples Current release: v7.13.0
Local-first · Cross-domain orchestration on explicitly allowed hosts · No data collection · Safe-by-design browser model
Start with the SDK How it works Read docs Examples
Go from idea to first working flow in minutes with plain JS, the SDK, examples, and AI-assisted implementation.
Planned hero visual: one local page driving a real tab on another allowed domain
Master tab
Your own local page script sends explicit requests from app.example.
Controller app.example
→
Controlled tab billing.example.org
allowed through the extension model
Named real tab
A visible controlled tab reused with tabKey, still debuggable like a normal Firefox tab.
No server No proxy No cloud relay Allowed domains only tabKey reuse
RTO does not bypass browser security. It uses explicit extension permissions plus an allow-list so your page can orchestrate a dedicated, visible tab on another allowed domain locally.
Immediate value

Useful from the first script

RTO is designed for browser-side workflows where you want real tabs, clear control, and less infrastructure overhead.

Named multi-tab workflows

Open and reuse named tabs with tabKey instead of juggling loose tab state.

Visible, real browser automation

Automate actual Firefox tabs you can see, inspect, focus, and explain to other humans.

No relay infrastructure

Keep orchestration local with no server, no proxy, and no cloud relay in the middle.

Easy to script

Start with the SDK, helpers, or copy-paste examples, then use coding copilots to adapt the flow faster.

Remote Tab Opener controlling a real tab on another explicitly allowed domain from a local admin page through the browser extension model and allow-list.
One local controller page can drive a real tab on another explicitly allowed domain through the browser extension model and allow-list.
This is cross-domain control, not a security bypass.
Who it is for

Built for practical browser-side work

  • Developers building internal control pages or admin panels.
  • QA teams that need visible browser workflows without heavy headless infrastructure.
  • Support tooling that opens the right page and guides the next action.
  • Product demos and guided walkthroughs that benefit from real tabs and visible overlays.
  • Ops and internal dashboards that need repeatable multi-tab browser flows.
Planned workflow visual: one master tab coordinating named tabs, overlay cues, and a live cross-domain browser run
tabKey: support Open the right help page once, then reuse it.
tabKey: qa Navigate a named test lane without losing track.
tabKey: demo Add overlay labels so the audience can follow the run.
Allow-list Keep target hosts explicit and deny-by-default.

Planned visual: one master tab coordinating named tabs, overlays, and a visible local workflow.

Why teams use RTO

Practical gains without a backend relay

Real tabs you can actually see

Open, navigate, focus, and inspect a visible tab instead of automating a hidden abstraction.

Local orchestration

Build internal browser workflows without adding relay services, proxies, or cloud runners.

Cross-domain on allowed hosts

Drive a real tab on another explicitly allowed domain from your own local page script.

tabKey keeps flows tidy

Reuse named tabs on purpose and keep multi-step flows easier to understand and debug.

Why it is different

A lighter fit for many real browser-side workflows

RTO is not trying to replace every automation stack. It fits the space between a plain tab helper, a macro recorder, and a full backend-heavy automation setup.

More useful than a simple tab switcher

You can do more than jump tabs: open them, reuse them, navigate them, and run safe predefined DOM actions.

More controllable than macro replay

You script explicit requests and selectors instead of hoping a recorded macro still matches the current page.

Lighter than headless-plus-relay setups

For many internal browser workflows, a local extension plus page script is simpler than building relay infrastructure.

Visual comparison between tab manager extensions, recorder and no-code tools, RPA and desktop automation, Selenium or Grid, with Remote Tab Opener positioned in the middle.
A quick visual guide to position RTO between tab helpers, recorder-style tools, RPA-style tools, and Selenium or Grid.
Compare RTO with other browser automation approaches
Useful if you are choosing between RTO, recorder-style tools, RPA-style tools, and Selenium or Grid.
AI-assisted implementation

Build faster with AI assistance

RTO works especially well with coding copilots because the model is explicit: a page script, a local bridge, named tabs, and clear error codes. AI can help draft starter scripts, adapt SDK snippets, turn a manual flow into a repeatable sequence, or debug request payloads.

Important: AI is not built into the plugin. It is simply a practical way to reduce implementation time around the SDK, helpers, and examples.

  • Draft a first controller page from the SDK.
  • Turn a manual QA flow into openTab, navigate, and DOM actions.
  • Adapt selectors and overlay steps faster.
  • Interpret returned errors and retry the right way.
Remote Tab Opener SDK used manually or with AI assistance to generate and adapt browser workflow scripts faster.
Start with the SDK manually, or use chatGPT AI assistance to generate, adapt, and debug your first RTO flows faster.
Two ways to build

Start visually, use the SDK directly, or mix both

RTO can fit both code-first and human-friendly workflows. Use a visual dashboard when you want a more guided interface, use the JavaScript SDK when you want explicit control, or combine both depending on the task.

Comparison between a visual human-friendly RTO dashboard and the Browser Extension RTO JavaScript SDK, showing that both approaches can be used depending on the workflow.
Use an accessible dashboard, work directly with the SDK, or combine both when the workflow benefits from it.
Technique, but not the full reference

How it works in one practical pass

1Your own page becomes the master tab and sends requests through the local bridge.
2The extension validates the host model, including the deny-by-default allow-list and explicit extension permissions.
3RTO can then target a dedicated tab on another allowed domain by tabKey or tabId, and open, reuse, or navigate it.
4Predefined DOM actions run inside that real tab, so the flow stays visible, local, and debuggable.
Open How it works Open documentation Browse examples
Planned architecture visual
Your page
Local controller script, SDK, or helpers on app.example.
extension permissions + allow-list
Named real tab on an allowed host
Open, reuse, navigate, focus, and automate billing.example.org via tabKey.

The full version of this visual will illustrate one local page orchestrating a real tab on another allowed domain without backend relay infrastructure.

FAQ

Short answers to the first practical questions

Do I need a server or proxy?

No. RTO is local-first and runs in the browser without a server, proxy, or cloud relay.

Does this bypass the Same-Origin Policy?

No. RTO respects browser boundaries and only works on hosts you explicitly allow.

Is it free?

Yes. The Firefox extension is free to install, and the site also exposes the free SDK, examples, and documentation.

How do I manage more than one tab?

Name them with tabKey values such as support, qa, or demo, then reuse those keys across actions.

Current release

What is new in v7.13.0

  • openTab now coalesces identical requests and stays serialized per tabKey.
  • navigate and allowlistAddRequest reject duplicate in-flight spam more defensively.
  • Controlled tabs now show the clearer WARNING : This tab is controlled by RTO banner text.
  • Helpers, examples, docs, and the public SDK were refreshed together for the current 7.13.0 flow.
View the complete changelog