How ChatLite handles your data

What stays on your device

Your nickname, avatar, contacts, rooms and chat history are stored in your browser (IndexedDB and localStorage). If you sign in, your session tokens are kept there too. Clearing site data removes them.

Calls and screen sharing

Audio, video and screen sharing use WebRTC. Browsers first try a direct connection, using a public STUN server to discover their network address. If that is not possible, a relay (TURN) may be used when one is available. ChatLite does not run its own relay server and the third-party TURN entry it still lists has no availability guarantee, so on some networks a call cannot connect. Media is encrypted with DTLS-SRTP, so a relay, if used, forwards encrypted traffic but can see connection metadata such as IP addresses and timing.

Messages and files

When two browsers are directly connected, one-to-one messages and files travel over an encrypted WebRTC data channel. Otherwise they are sent through our server over an encrypted WebSocket. Group messages always go through our server. If the recipient is offline, items are queued: in server memory (up to 50 per user, cleared when the server restarts) or, for devices linked to an account, in our database for up to 14 days. Files sent through the server are limited to 8 MB; direct transfers are limited to 100 MB.

What our server sees

Our server handles connection setup (signaling), online status, typing indicators, read receipts, and the nickname, avatar and status message you share with contacts. For the messages and files it relays, it can technically read the content, because ChatLite does not currently provide application-level end-to-end encryption. Operational logs may include nicknames and anonymous user IDs. If you use the Contact form, the message, and the name and e-mail address you choose to enter, are stored on our server only so that the operator can read and answer them.

Push notifications

If you enable notifications, your browser registers a token with Google Firebase Cloud Messaging. When you are offline and receive a message, a notification containing the sender name and the beginning of the message (or the file name) is delivered through that service.

Optional accounts

You never need an account to chat. If you create one, we store your email address, a bcrypt-hashed password, your linked devices and session records (refresh tokens are stored hashed). Accounts enable the multi-device delivery described above.

Usage measurement

ChatLite has first-party usage measurement that the operator can switch on or off, and it uses no third-party analytics for this. When it is on, ChatLite records short product events, such as that the landing page or the app was opened, an invite was created or opened, a friend was added, a direct or server connection succeeded or failed, a message, file, call or screen share was used, and roughly how long a session lasted, together with coarse context: page language, browser or installed app, device class and browser family. It does not record message or file content, file names, nicknames, e-mail addresses, user IDs, room IDs or IP addresses, and requests from automated clients are excluded. Events are linked by a random identifier that exists only in the open browser tab, and invite links can carry a random token used to count invites that lead to a conversation; a browser that opened an invite also remembers that fact for 7 days. Event rows are deleted after 14 days and only daily totals without identifiers are kept longer. This is limited event metadata for understanding whether the product works, not a profile of you, but it is not anonymous in the strict sense: your browser's IP address is visible to any server it contacts, as described under what our server sees. When measurement is off, nothing is generated or stored.

Advertising

ChatLite's public website pages (the home page, guides, tools, articles and the About page) show ads served by Google AdSense. Google and other third-party vendors use cookies to serve ads based on a person's prior visits to this website or other websites. Google's use of advertising cookies enables it and its partners to serve ads to you based on your visit to this site and/or other sites on the Internet. You can opt out of personalized advertising in Google's Ads Settings at https://adssettings.google.com. The chat application itself (the pages under /app/) shows no ads and loads no advertising code, and the browser tools never send your camera, microphone, screen or network addresses to us or to advertisers.

Browser tools

The screen recorder, voice recorder, webcam tool and QR code generator work entirely in your browser. Recordings, photos, camera pictures, microphone sound, shared screens and the text you put into a QR code are not sent to our server or to anyone else, are not stored in your browser and are not counted by our usage measurement. They exist in the memory of the open tab until you close or reload it; what you download is a file on your own device. The camera and microphone test and the screen share check work the same way.

The call quality test is the one tool that contacts our server, and only after you press its button. It sends 30 plain requests without cookies to a fixed address on this site and times the answers in your browser. The ChatLite application replies with a constant tiny answer, does not store the requests or your result, and writes no log line for them. In ChatLite's web server configuration the access log is switched off for this one address. Any web server or network between you and this site can in principle keep its own records, and this page can only describe how ChatLite itself is set up. To resist abuse the application counts requests per network address in memory for one minute and refuses more than a fixed number; that counter is never written to disk. No bandwidth test is offered, to avoid load on the server.

The WebRTC connectivity test asks Google's public STUN servers for your public address, as every WebRTC call does; the addresses are shown on your screen and are not sent to us. If an in-app browser (for example inside a messenger) is detected from its user-agent string, the tool pages show a hint to open the page in your regular browser; that check runs in your browser and nothing is sent.