videochatrabbitvideochatrabbit.co
In-app browsers

Out of the little window, into a real browser.

Tap a link inside a social app and it usually opens in that app's own cut-down browser. videochatrabbit.co asks for the system browser instead wherever the platform allows it — and where it does not, the visitor still arrives, just in the window they started in.

The hand-off, one rung at a time

Every rung is optional except the last one. If a rung is not available, the next one still works.

1
The tap

Someone taps your short address inside a chat or social app. The app opens it in its own embedded browser, which is what it always does.

2
The ask

Our server resolves the code and answers in the way that asks the platform to continue in the device's own browser, where that platform honours it.

3
The landing

Honoured or not, the destination loads. Worst case the visitor stays in the embedded view and still gets there; best case they are in a full browser.

Why anyone cares

Embedded browsers are deliberately small. They tend to lack the extensions, saved logins, password autofill and payment details the visitor set up in their real browser, and sharing a page back out of one is awkward. None of that is a fault in your destination — it is the window the link was opened in.

saved loginspassword autofillextensionsreader modeproper address barshare sheetbookmarksback to your tabs
Edge cases, stated plainly
Does this always escape the in-app browser?

No, and nobody can promise that. Whether an embedded browser hands off to the system browser is the platform's decision, and platforms change it. Where the hand-off is refused, the link still resolves and the visitor still reaches the destination inside the app.

Is anything installed on the visitor's device?

No. There is no app, no extension and no prompt to install one. It is an ordinary web request that ends in a redirect.

Does the destination change depending on the app?

The destination is whatever its owner set. What can differ is the window it opens in.

What about links opened on a desktop?

They open in the browser that made the request, which on a desktop is already a full browser. Nothing extra happens.

Do you host what is on the other side?

No. The service stores a destination against a short code and forwards to it. The destination belongs to the person who created the link.