Privacy

A recording is not a video. It is a description of the page — its structure, its text, and the changes to both — together with the visitor’s clicks, scrolling, mouse movement and typing. Replaying it rebuilds the page from that description.

A recording can therefore contain what a visitor typed into a form: a name, an address, a message, an order number. Whether it does is the customer’s decision. The recorder masks form fields by default, replacing a value with asterisks in the browser before anything is sent; a customer can turn that off to see what visitors type, and can mask more — a single element, or everything typed anywhere on the page. What no setting can switch off is the list in “What is never recorded” below.

Alongside it we store, for each session:

• A random visitor identifier generated in the browser. It is not linked to any identity unless the customer chooses to send one.
• The page addresses visited, the browser, the operating system, the device type and the screen size.
• The language the browser reports, which is what the translation feature starts from.
• An approximate country and city, and with them a region and time zone, as the network operator in front of our recording endpoint resolves them at the moment the session begins. Nothing narrower is stored: no postcode, no coordinates, no street.
• Anything the customer chooses to add: an identifier or email address passed to identify(), and the properties of custom events they track.
• What the page’s own code reported went wrong while it was being recorded — see below.

We do not store the visitor’s IP address. The recording endpoint uses it in memory, for a moment, to apply rate limits, and writes it nowhere — not to the session, not to a log. The location above is not derived by us from an address we hold: our network provider, Cloudflare, resolves the address as the request passes through it and tells us only the result — country, city, region and time zone. We read that from the very first request of a session, store it on the session, and never change it afterwards, so a visitor who moves does not rewrite a recording somebody has already watched. A deployment without such a network in front of it — a customer hosting AnyReplay themselves — records no location at all. The browser’s identification string is reduced to browser, operating system and device type, and is not kept.

A recording also carries what the page said about itself while it ran, because a replay of something that broke is only useful next to the reason it broke. Three things are kept, each of which a customer can switch off:

• Uncaught errors: the message, the error’s name, its stack, and the file and line that threw.
• Console messages written with console.error or console.warn — whatever the page chose to print there. Ordinary log, info and debug messages are not recorded at any setting.
• For each request the page made: the method, the address, the status code and how long it took.

No request or response body is ever recorded, and no request headers or cookies — not a sample of one, not a shortened one. What a page sent to its own server, and what came back, stays between them.

Addresses and messages are cleaned in the browser before they are sent: a query value whose name says it is a secret — a token, a key, an authorisation, a code, a signature — is replaced, as is anything shaped like an email address, any long opaque identifier and any number shaped like a payment card. The part of an address after #, which never reaches a server, is dropped entirely, and so is a user name or password written into the address itself. A console message is the least predictable of the three, since it is whatever a customer’s own code prints; the same cleaning runs over every one, and a customer whose pages print personal data can turn that stream off and keep the other two.

Masking is applied in the visitor’s browser, or on their phone, before anything is sent: a masked value is replaced with asterisks of the same length, so the original characters never leave the visitor’s device and cannot reach us even by accident. The values below are masked in every configuration, and there is no setting a customer can use to record them:

• Passwords, and one-time codes: any field of type password, any field a browser would fill with a saved password or a verification code, and any field named or labelled as one.
• Payment card details: the card number, the security code (CVV/CVC), the expiry date and the cardholder name — recognised from the field’s autocomplete value or from its name, label or placeholder — and bank details such as an IBAN, a routing number or a sort code.
• Any value that has the shape of a payment card number, wherever it was typed.
• In a mobile app, any field the operating system is told is a password, a one-time code or a payment field, and any field whose label, placeholder or test identifier names one.
• Anything inside a script or style tag.

Email and telephone fields are not on that list. An address and a phone number are ordinary contact details rather than credentials, so they are recorded like any other form field and masked whenever the customer turns masking on or marks the field.

Beyond that floor, the customer decides. The contents of other form fields — and the text a visitor types into a rich-text editor — are recorded unless the customer turns masking on, and anything the customer marks with the ar-mask class is masked while elements marked ar-block are left out of the recording altogether. It is the customer, as the controller of their visitors’ data, who chooses the level and who is responsible for it; we provide the controls, apply them in the browser, and document exactly what each one does.

The recorder can be told to record nothing until consent is given, and to stop at any time. Whether to use that is the customer’s decision, because it is the customer who has the relationship with the visitor and who is the data controller for the recording. We process it on their instructions.

When a reviewer asks for a session in another language, the text of the recorded page is sent to a language model to be translated — today OpenAI’s gpt-5-nano, called directly rather than through a gateway. Masked values are never included, because they were never recorded. Translated strings are cached for the organisation that paid for them so that the same sentence is not translated twice; the cache is keyed by the text, never by which session it came from, and is never shared between organisations.

Each organisation sets its own retention period: anything from one day up to the ceiling its plan allows, which is fourteen days on the free plan and a year on the largest. A new organisation starts at fourteen days; an organisation created before 20 September 2026 started at thirty and keeps it until it chooses otherwise. A sweep every few hours deletes recordings past that period, both the stored data and the index that points at it. Deleting a session by hand deletes the recording in the same way, at once.

Recordings are also deleted when:

• The customer files an erasure request for a person — by their user id, email address or visitor id — which removes every matching recording across the organisation’s projects.
• A project is deleted.
• An owner closes the organisation. Closure takes effect after a thirty-day grace period, during which it can be cancelled; then the organisation and everything in it is deleted.

Deleted data does not vanish from every copy at the same instant, and we would rather say so plainly. When we delete a recording — a retention sweep, a session or project somebody deleted, an erasure request — it goes from the service at once. A recording still held on our own server is deleted with it; one already in object storage is hidden by the storage provider immediately, and the bytes themselves are removed seven days later. That window is deliberate. It is what would let a deletion nobody intended — a bug of ours, a stolen key — be undone before it is final, and it is why “deleted” here means gone within seven days rather than in the same instant. Nothing is read back from it in the ordinary running of the service.

Backups are the other copy. They are encrypted on our own server before they leave it and age out after thirty days, and while recordings are stored on our server rather than in object storage they are included in them — so a deleted recording, and the details of the session it belonged to, can survive in an encrypted backup for up to thirty days. Backups are restored only to bring the service back after a failure, never to retrieve one recording.

One thing outlives a closed organisation on purpose: the record of money that moved. The billing events behind an organisation’s payments are kept for accounting with the organisation’s identifier removed from them. They hold what the payment provider sent us about a charge, which can include the buyer’s name and email address.

If you sign in with Google we ask Google only for your name, email address and profile picture. We do not request access to your mail, files, calendar or anything else, and could not read them if we tried. We store the identifier Google gives us for your account, so that we recognise you next time even if you change your address.

For the people who use the dashboard we are the controller of their account data: name, email address, language, the organisations they belong to and their role in each, and a record of sign-ins. Sign-in and sign-up entries in the organisation’s audit log include the IP address and browser they came from, so that owners can spot a sign-in that was not theirs. We keep account data while the account exists and delete it when you delete the account; the organisation’s audit entries then keep what was done but no longer carry your name.

We use your email address to send what the service needs — verification links, sign-in codes, invitations, usage notices and contractual notices — and nothing else. Usage notices can be switched off; the others cannot, because they are how the account works.

The endpoint that receives recordings keeps no access log. The dashboard and API keep access logs for diagnosing errors and abuse, with the address shortened before it is written (the last part of an IPv4 address, and everything after the first three groups of an IPv6 address, are removed) and without query strings, referrers or browser details. Error logs on the server may contain a full address; they are short-lived and read only to fix problems.

Our own website asks before it loads anything optional. Your answer is stored in a first-party cookie called ar_consent for six months, so we do not ask on every page; you can change it at any time from the cookie settings link in the footer.

Signing in to the dashboard sets one more first-party cookie, ar_rt, which keeps you signed in. It is strictly necessary and set only when you sign in. Starting a Google sign-in sets two more on our API, ar_gs and ar_gi, which last ten minutes and exist only to prove the sign-in you come back with is the one you started.

Google Analytics 4 (to count visits) and Google Ads (to measure whether an advert led to a sign-up) are loaded only after you accept them. If you reject them, or never answer, neither script is requested and no Google cookie is set. They never run in the dashboard or on our customers’ sites.

Recordings are visible to members of the organisation that owns them, according to the role they were given. They are never shared between organisations. The service relies on a small number of providers, each under contract and each receiving only what its job needs:

• Hetzner, which hosts our servers and database in data centres in Germany.
• Cloudflare, which sits in front of every AnyReplay address and protects it; requests, including their IP addresses, pass through its network.
• Backblaze, which stores recordings and our encrypted off-site backups.
• Brevo, which sends our transactional email and so receives the recipient’s address and the message.
• OpenAI, whose language model receives the text to be translated and nothing else.
• RevenueCat, which checks the App Store and Google Play receipts behind a subscription and tells us which plan an organisation is on; it receives the organisation’s identifier and the receipt, never a name or an address.
• Sentry, which receives error reports from our services with request bodies, cookies, IP addresses and user details removed before they are sent.

The sub-processor page lists each one with where it processes data and how transfers outside the EU are safeguarded, and logs every change. Customers can accept our data processing agreement from the dashboard, and our security page describes how the data is protected.

If you believe a site recorded you and you want that recording deleted, the request goes to the site that recorded you — they decide what happens to it, and we act on their instruction. If you cannot reach them, write to us at [email protected] and we will help you find who to ask.

[email protected]