Btwinus vs otr.to: which one should you use for a private chat?

otr.to launched in 2015 and got a burst of attention for bringing the Off-the-Record protocol into a web page. Btwinus arrived much later with the same instinct, WebRTC, browser only, nothing stored, but a different answer to the hard question of signalling. This post is mostly about that question, because it's where the two actually differ.

What otr.to is

otr.to is a peer-to-peer chat in the browser, tagline "Anonymous, no logs, no servers". There's no account. Historically you got a short temporary code, shared it, and the other person used it to connect; messages then flowed over a WebRTC data channel between the two browsers, so nothing passed through a chat server. The original 2015 code, published under the Apache 2.0 licence, built on three open libraries: PeerJS for the WebRTC plumbing, a JavaScript implementation of the OTR protocol for message encryption, and CryptoJS for a separate "self-destructing message" feature that stored an AES-encrypted note on a server with the key kept client-side.

Here's what we could and couldn't verify in 2026. The site is up and still built on PeerJS, the current bundle points at PeerJS's public signalling and TURN servers plus Google's STUN. That matters: PeerJS needs a broker server so that two browsers can exchange connection details before they talk directly. The broker doesn't see your messages, but it does see that two peers connected, from which addresses, and when. "No servers" is true of the chat itself, not of the introduction. The public GitHub repository hasn't had a commit since 2015 and its README is two lines; the live site appears to have been rebuilt since, and we couldn't confirm from the shipped code whether the OTR protocol is still applied on top of WebRTC's own transport encryption. The self-destructing-note page returned a 404 when we checked. We also couldn't find documentation of group chat or file transfer, so we're treating both as unsupported. If you know otherwise, the site's own code is the source of truth.

None of that is an accusation. It's a one-person open source project from a decade ago that still runs, which is more than most. But if you're choosing it for a sensitive conversation, you should know that some of its 2015 description may not describe what's deployed today.

What Btwinus is

Btwinus is also a one-to-one WebRTC chat with no account, but it removes the broker. When you click "Start a new chat", your browser creates a WebRTC offer, compresses it, encrypts it with AES-256-GCM using a key derived from a generated passphrase (PBKDF2, 100,000 iterations), and puts the result in the URL fragment of an invite link. You send that link one way and the passphrase another. The other person opens the link, enters the passphrase, and their browser produces a reply link the same way; you paste it in and the connection is up. The introduction travels inside the links themselves, no signalling server, no room code, nothing for a third party to log.

Once connected, messages go directly between the two browsers over WebRTC's built-in DTLS encryption. Both sides see a short authentication string to compare out loud, which catches a man-in-the-middle on the handshake. Close either tab and the session is gone. It's free, has no ads, and is open source with recent commits; the whole app is a static page. (Details in how Btwinus puts AES-256 in a link.)

The costs are the same shape as otr.to's: two people, both online, text only, no history. Plus one that's specific to Btwinus: the handshake asks more of the recipient, open a link, type a passphrase, send a link back.

The honest comparison table

Property	otr.to	Btwinus
Account required	None	None
Message transport	WebRTC, browser to browser	WebRTC, browser to browser
How peers find each other	PeerJS signalling server (public broker)	Encrypted offer/answer inside the links
Server in the loop	Signalling broker + STUN/TURN	STUN only, for address discovery
Secret that gates the chat	Short code / link	Link + passphrase on separate channels
Message encryption	OTR over WebRTC in 2015 source; unverified in current build; DTLS regardless	AES-256-GCM handshake; DTLS on the channel
Handshake verification	OTR supports it in principle; not confirmed in the current UI	Short authentication string on both sides
Both online at once	Yes	Yes
Groups	Not documented	No
Files	Not documented	No
Open source	Yes (Apache 2.0), last commit 2015	Yes, actively maintained
Self-hostable	In theory, with your own PeerJS server	Yes, static files
Cost / ads	Free, no ads seen	Free, no ads

Where otr.to is the better choice

Simpler to start. A broker means you can hand someone a short code and be connected in seconds. Btwinus's link-then-passphrase-then-reply-link flow is more to explain, especially on a phone.

Shorter links. Btwinus links carry a whole compressed, encrypted WebRTC offer, so they're long. otr.to's are short, which is nicer for reading out loud or typing.

TURN relay for hostile networks. The current otr.to bundle lists TURN servers. If a direct connection can't be made, some corporate firewalls, some mobile carriers, TURN relays the encrypted stream and the chat still works. Btwinus uses STUN only and has no relay fallback, so on those networks it may not connect at all.

You specifically want the OTR protocol. If OTR's deniability properties are what you're after and the current build does still use it, otr.to is the only one of the two offering it. Just verify that yourself first.

Where Btwinus is the better choice

Nobody is introduced by a third party. With otr.to, a public PeerJS broker learns that two peers connected, their addresses and the time. Btwinus moves the introduction into the links, so the only servers involved are the static host that serves the page and a STUN server that tells your browser its own public address. There's no metadata trail of "these two talked".

Two secrets on two channels. A code that anyone can type is a single secret. Btwinus always splits link and passphrase, so an attacker reading one channel has nothing. (This is the same principle behind sharing a password without leaving a copy behind.)

You can verify the handshake. Both people read out a short code; if it differs, someone's in the middle. We couldn't confirm otr.to surfaces anything equivalent today.

You can see what you're running. Btwinus's deployed code matches its public repository and is maintained. otr.to's repository is a decade old and the live bundle has clearly moved on, so what you're auditing isn't what you're using.

Wrong passphrase fails loudly. AES-GCM's authentication tag means a mistyped or wrong passphrase simply refuses to decrypt, you get a clear error, not a silent bad connection.

How to decide

• Quick chat with a friend, low stakes, awkward network → otr.to.
• Something that matters, and you'd rather no broker know the two of you connected → Btwinus.
• You want to audit the code you're actually running → Btwinus.
• Recipient who can't handle a two-step handshake → otr.to, or a phone call.
• Groups, files, offline delivery → neither; see Signal vs Telegram vs Btwinus.

These two are siblings. otr.to showed in 2015 that a browser could do this at all. Btwinus takes the last server out of the room and pays for it in link length and a slightly longer handshake. Whether that trade is worth it depends entirely on how much the fact of the conversation needs to stay private, not just its contents.