Learn / Does Signal have a web version?
Explainer · updated for 2026
Does Signal have a web version?
A lot of people search for "Signal web" hoping to open a tab and start messaging. Here is the straight answer, the reasoning behind it, and what your options actually are.
Short answer: No — Signal has no web or browser version, and its developers have explicitly declined to build one. Signal Desktop is an installed application that must be linked to a phone already running Signal. If you need end-to-end encrypted messaging in a plain browser tab with nothing installed, you need a different tool built for that trust model.
Last updated July 6, 2026 — re-verified Signal's web-client stance against the closed GitHub request. Living page — corrections welcome.
What Signal actually offers
Signal runs on phones and desktops — as installed software only. The full lineup:
- Signal mobile — native apps for Android and iOS. This is the primary device; every Signal account lives on a phone.
- Signal Desktop — an installed Electron application for Windows, macOS, and Linux. It is not standalone: you must link it, via QR code, to a phone that already runs Signal.
- Signal in a browser tab — does not exist. There is no signal.org web app, and this is deliberate: the long-standing request for a browser client was closed, and Signal has never shipped one.
Practical consequence: if you can't install software — a locked-down work laptop, a library or school computer, a borrowed device — you can't use Signal on it. That's not an oversight; it's a decision, explained below.
Why Signal says no
Signal's refusal deserves to be presented honestly, because it's a principled position, not laziness. Three concerns drive it:
Code delivery on every visit
A web app receives fresh code from the server every time you open it. That means a compromised — or legally coerced — server could serve malicious JavaScript to one specific user, once, and quietly exfiltrate keys or plaintext. An installed app's code changes only when you update it, which makes targeted tampering far harder and more detectable.
The browser's attack surface
Browsers host extensions with broad page access, and a malicious or compromised extension can read what's on the screen or in the DOM. The browser environment simply has more moving parts between the crypto and the user than a dedicated installed app does.
Weaker key storage
Long-term secret keys stored in browser storage (IndexedDB, localStorage) enjoy fewer OS-level protections than keys held by an installed app, which can use platform keychains and hardware-backed stores.
A coherent conclusion
Given Signal's threat model — high-risk users, nation-state adversaries — the team concluded the browser's guarantees weren't strong enough, and chose not to ship a client it couldn't stand behind. Whatever you think of the tradeoff, that is engineering integrity, and it's the same reasoning behind Signal's other famous requirement: the phone number.
What a browser E2E messenger has to solve
Signal's objections are real problems, not excuses. Any messenger that does run encrypted messaging in a browser has to answer each of them directly:
1. Code-delivery integrity
Since the server ships the code, the delivery pipeline itself must be hardened: a strict Content Security Policy so no unexpected script can run, and subresource integrity so the assets the page loads must match known cryptographic hashes. This narrows "the server can serve anything" toward "the server can serve only what it committed to."
2. In-browser key storage
Keys have to live somewhere the browser protects as strongly as it can — origin-isolated storage, non-extractable key material where the platform supports it — while being honest that this still trails an installed app's access to OS keychains and hardware-backed storage.
3. One crypto implementation, not two
The subtle failure mode is shipping a second, JavaScript rewrite of the protocol for the web that slowly drifts from the native implementation. The robust answer is compiling the same crypto code to WebAssembly, so browser and native app run one implementation with one set of bugs to find and fix.
Sendant's approach: take the browser problem on
Sendant made the opposite call from Signal: the browser is exactly where private messaging is missing, so the hard problems above are worth solving rather than avoiding. Sendant is, as far as we know, the only identifier-free messenger with a persistent, full-featured no-install browser client — open app.sendant.io and you're messaging, with no phone number, no email, and no account. The browser runs the same WASM-compiled X3DH + Double Ratchet crypto path as the native app, so there is no second implementation to drift. On an iPhone, Sendant works in the browser — there is no native iOS app yet.
Honest tiering: the browser client is Sendant's low-friction tier — the way in when you can't install anything. An installed app remains the higher-assurance tier, for exactly the reasons Signal articulates: stabler code delivery and stronger key storage. And Sendant has not yet been independently audited; an audit is planned, and known limitations are documented rather than hidden. If audited maturity is your top requirement today, Signal wins that row.
If you just need Signal: this page isn't a trick to switch you. If your contacts are on Signal and you can install apps on your devices, Signal Desktop plus the mobile app is a mature, heavily audited setup — use it. The browser question only bites when installing isn't an option or a phone number is the dealbreaker; see the full Sendant vs Signal comparison for where each one wins.
Common questions
Can I use Signal without installing anything?
No. Every way of using Signal requires an installed app: the mobile app on Android or iOS, and Signal Desktop, which itself must be linked to a phone that already runs Signal. There is no signal.org page you can open in a browser and start messaging from.
Why doesn't Signal make a web app?
Because Signal's team considers the browser trust model too weak for its threat model. A web app receives fresh code from the server on every visit, so a compromised or coerced server could ship malicious JavaScript that steals keys or plaintext. Signal has explicitly declined to build a web version rather than accept that risk. It is a principled engineering position, not a missing feature.
Are browser-based encrypted messengers safe?
The browser is a genuinely harder trust model: you re-trust the server's code delivery on every visit, and key storage in a browser is weaker than in an installed app. Mitigations exist — strict Content Security Policy, subresource integrity, and running the same audited crypto implementation compiled to WebAssembly rather than a separate JavaScript rewrite — but an installed app remains the higher-assurance option. A well-built browser messenger is a reasonable low-friction tier, not a replacement for a native app when the stakes are highest.
What can I use in a browser instead?
Ephemeral encrypted chat rooms exist on the web, but they are one-off links, not persistent messengers with contacts and history. Sendant is a persistent, full-featured encrypted messenger that runs entirely in the browser at app.sendant.io, with no phone number, email, or install — the browser is its low-friction tier, and an installed app remains the higher-assurance tier. See how it stacks up in the Sendant vs Signal comparison.