We trust no intermediary. So we removed every intermediary.
One HTML file is the whole of Bytz. Share that file with the other person, send a single invite key, and the conversation starts. No app store, no phone number, no account handoff. Everything runs right inside the browser already showing this page.
| Item | Telegram | Signal | Bytz |
|---|---|---|---|
| Phone number required to sign up | Required | Required | None |
| App install / store dependency | Required | Required | None — one HTML file |
| Default E2E in 1:1 chat | Secret Chat only | Yes | Yes |
| Verify the client you received yourself | No | No | Yes (file hash) |
| Message ratchet granularity | Rekeying (100 msgs / 1 week) | Per-message (Double Ratchet) | Per-message (Double Ratchet) |
| Reset the whole conversation | Available | Limited | Both sides + pending messages cleared |
No install, no sign-up, nothing extra in between. The flow is just three steps.
Download a single HTML file. If you want to see what is inside, open it in a text editor and read the code directly.
Open the file in your browser and create a room with a passphrase you choose yourself. The passphrase never leaves your device. If you lose it, there is no path back to the same room, so keep it somewhere safe from the start.
Generate an invite key from the room's settings and send it to the other person. They enter that key together with a passphrase of their own, and from that moment both sides line up the session automatically. The passphrase belongs to each side and never crosses over.
Telegram and Signal both ask for a phone number at sign-up. The number creates the account, the account ties together the conversations, and the conversations lead back to the number. Once that link exists, it is hard to fully separate later. Bytz removes that starting point. It connects people with room keys and session keys only, so information the service never collected cannot leak from somewhere else later.
In Telegram, end-to-end encrypted chat requires opening Secret Chat separately. If you forget and send something in regular chat, plaintext stays on the server. Bytz removes that choice. It does not have a separate mode like Secret Chat. You can think of it as only having that mode to begin with.
The Bytz server only relays encrypted frames between the two browsers. It does not store message contents, and it does not store the keys needed to decrypt them. What the server actually sees is limited to participant-identifying hashes and frame length buckets; the body of the conversation and the contents of files stay outside that view. Even when the other side is briefly offline and a message waits in the queue, it stays encrypted and is deleted once delivery succeeds. Even if the server is breached or seized, what comes out is ciphertext without the keys needed to read it.
The invite key the room's host creates is used for proof only inside the joining device. What the server registers is the public half; at the moment of joining, the private half is never sent across the wire. The server issues a fresh random challenge and only checks that the answer, solved in place by the other side, lines up. The invite key is designed so that it does not brush the server logs even once.
When we install a messenger, we usually trust the app store and move on. Users are not given a practical way to verify whether the file is really the official release. Bytz puts Verify HTML hash on the main screen. You can calculate the SHA-256 of the file directly and compare it with the official published hash. Since the whole client is a single file, you can also open it and read it yourself if you want to inspect it.
Session ECDH private keys are generated with extractable: false. The browser
API refuses any export attempt, and when the conversation tab closes they leave memory
along with it. Longer-lived keys do stay in browser storage, but only after being wrapped
in AES-GCM under a key derived from the passphrase you chose. Even if someone copies the
whole file from the device, without that passphrase the keys inside cannot be taken out
again.
Reset conversation is not a button that only clears your local history. It deletes the record on the other device too, and it also clears messages that have not been delivered yet. If deleting sent messages feels like editing, resetting the conversation is closer to disposal. It closes the conversation itself on both sides at the same time.
When registering a personal phone number upfront already feels like too much exposure. It works well when you need to make contact, confirm the substance, and end the exchange cleanly.
Reporting where both who talked to whom and what was said are sensitive. You can start without a phone number, and when the conversation is over it can be cleared from both devices together.
When an incident breaks and you need an urgent channel that is not tied to the accounts you normally use. Share one file and a live conversation channel can be up in minutes.
A one-off collaboration, a single outside contact, or any exchange you would rather not see tied back to your day-to-day account. Nothing is left behind in your contacts, address book, or the messenger you usually use.
Each outgoing message advances the working key by one step. On top of that, every round-trip swaps in a fresh secret built jointly by both sides, replacing the underlying key entirely. Even if one key is exposed, the messages before and after it do not come unlocked along with it.
It layers an ML-KEM-768 shared secret on top of ECDH(P-256) to derive session keys, and message signatures are produced and checked with ECDSA and ML-DSA-65 together. The point is to hold up against attacks now, and also against attempts to decrypt or forge later once practical quantum machines exist.
Whether it is a regular message, a session-handshake signal, or a conversation-reset command, the receiving side checks the signature first. A timestamp window and a replay cache are inspected together, so a captured old frame is not accepted even if someone tries to slip it back in later.
If you ask users to compare long numeric hashes, most people will not do it. Bytz turns the fingerprint into six words so the check is short enough to actually perform. A verification flow only matters if people will really use it.
Outgoing frames are padded to fixed size buckets. Right before send, they are also mixed with 0-500ms of jitter. Even when the content is encrypted, length and timing still leak information. This blurs those clues too.
It does not load external scripts, fonts, or images. The browser's Content Security Policy blocks outbound calls at the source, so even tampered code has no path to leak data to another server. With the whole client concentrated in one file, anyone who wants to read it, inspect it, and judge it for themselves can do so directly.
Every security tool has an outer boundary. It is better to be explicit about what Bytz does not solve.