What we keep in your browser.

How Transglot uses cookies and similar technologies, such as local storage, on the marketing site and inside the product, what each one does, how long it lasts, and what you can do about it. Each entry below names the cookie exactly as your browser will show it. This document is part of the Privacy Policy, which explains everything else we do with personal data.

A cookie is a small text file a site asks your browser to keep and send back on the next request. Local storage is a related mechanism that keeps a value in the browser without sending it anywhere, so nothing in local storage ever reaches our servers unless the page deliberately puts it in a request. We use both, sparingly, and this document lists both. We use no device fingerprinting, no social network pixel and no share-button tracker. We do use advertising identifiers, and they are the newest thing on this page: a click identifier that a Google ad appends to the address it sends you to, the two cookies Google writes from it, and one cookie of our own that keeps the same identifier where the browser cannot reach it. All three are named below. One Google script serves both the analytics half and the advertising half, because Google’s rule is one tag to a page.

Under the ePrivacy rules, consent is needed for anything that is not strictly necessary to deliver the service you asked for. Most of what we set is exempt: the session and the form protection are strictly necessary, the theme and the sidebar are preferences you set yourself by using a control on the page, the partner cookie is the record of a link you followed, and the consent cookie is the record of your answer. The two Google Analytics cookies and the three advertising cookies are not exempt. Visitors in the European Economic Area, the United Kingdom and Switzerland are shown a banner, and until it is answered every one of those five is denied: the Google tag loads, but it writes no analytics cookie and neither of Google’s two advertising cookies, our own advertising cookie is not written either, and what reaches Google is a ping carrying no cookie and no click identifier. The answer is kept in tg_consent for 180 days and covers the website and the product together, so the banner asks once rather than at every crossing. Whether you are shown it at all is decided from the time zone your browser reports, because we look up nobody’s IP address and will not add a vendor that does; where that guess misses, Google’s own region check still denies the data until an answer arrives. Everywhere else the default is granted, which is a decision we took rather than one the law took for us. Wherever you are, you can refuse right now by blocking cookies for this site in your browser settings, by reading in a private window, or by running any content blocker. Every feature of this site and of the product works without any of them, so refusing costs you nothing.

The sign-in session. It holds an identifier that points at a session record on our own servers, not your data, and it is what keeps you signed in as you move between screens. Set by us as a first party cookie on the host you are on, marked HttpOnly so page scripts cannot read it, with SameSite set to Lax, and encrypted. It expires after 120 minutes of inactivity, and each host (the marketing site, the app, the API and the admin surface) keeps its own separate session rather than sharing one. Blocking it means you cannot sign in.

Cross site request forgery protection. It carries a token the page reads and sends back with every form and every write request, so that a request coming from another site cannot act as you. Set by us as a first party cookie, deliberately readable by the page (that is the entire mechanism), with SameSite set to Lax, and it expires with the session at 120 minutes. Blocking it means every form on the site fails.

The persistent sign-in cookie, set only if you tick "Remember me" on the sign-in form. It holds a long random token, tied to your account, that lets a later visit re-establish a session without asking for your password again. First party, HttpOnly, encrypted, and long lived by design (Laravel’s default horizon for this cookie is five years). Signing out clears it. Do not tick the box on a shared computer, and if you think a device has been lost, change your password, which invalidates it.

The light or dark theme you chose inside the product, kept so the page can paint the right ground before the first frame instead of flashing white at you. Set by the page as a first party cookie with a lifetime of 365 days, readable by the page, and deliberately not encrypted so the server can read it during the first render. It holds one of three words: light, dark or system. Nothing about you is in it.

Whether you left the product sidebar open or collapsed, so it comes back the way you left it. Set by the page as a first party cookie with a lifetime of 7 days, readable by the page, not encrypted. It holds true or false.

Set when you answer the consent banner, and only then. It holds one word, granted or denied, and nothing beside it: no identifier, and no record of what you were reading when you answered. First party, deliberately readable by the page and deliberately not encrypted, because the script that has to act on it runs in the document head before any bundle has parsed, and the server has to read the same value back on the next request to declare the matching default to Google. SameSite Lax, a lifetime of 180 days, and scoped across our subdomains for the same reason the partner cookie is: the banner is answered on the website and the tag it governs also runs in the product, so a host-only cookie would ask the same person twice. Delete it and the banner asks again.

Set only when you arrive through a Founding Partner referral link or a link carrying a referral parameter. It holds a random 32 character token that identifies the link you followed, not you: no name, no email, no browsing history. If you later create an account, the token is what credits the partner who sent you. First party, HttpOnly, encrypted, SameSite Lax, with a lifetime of 60 days, which matches the attribution window in our partner terms. Like the consent and advertising cookies around it, it is scoped across our subdomains, because the link is followed on the marketing site and the account is created on the app. Delete it in your browser and no referral is ever recorded.

Set only when you arrive on a link carrying a Google click identifier, which is what a Google ad appends to the address it sends you to. It holds that identifier, the campaign parameters that came with it and the path you landed on, so that a conversion finished later, or finished where no browser is present at all, can be credited to the ad you actually clicked: a subscription confirmed by our payment processor hours after you closed the tab has no page to fire from, and this is how that conversion finds its click. First party, HttpOnly so page scripts cannot read it, encrypted, SameSite Lax, and a lifetime of 90 days, which is the window Google will still accept a conversion in and is deliberately not the 60 days the partner cookie uses. It is scoped across our subdomains, because the ad is clicked on the website and the account is created in the product. Refuse the banner and it is not written, and a refusal given afterwards stops one already in your browser from being read. Clearing this site’s cookies removes it outright, and a conversion you make after that is credited to nothing.

Three keys live in local storage rather than in a cookie, which means the browser keeps them and does not attach them to requests. "tg-theme" holds the light or dark choice for the marketing site. "appearance" holds the same choice for the product, mirroring the cookie so the page can react without a round trip. "taip:last-project" followed by your workspace name holds the last project you opened in that workspace, so the product can take you back there. Clearing site data in your browser removes all three and costs you nothing but those preferences.

The product and the website can carry an in-app support messenger from a third party support provider. When it is enabled it loads that provider’s script and the provider may set its own cookies and storage in your browser to keep a conversation together across visits, under its own privacy policy; when it is signed in it receives your name, your email address and your account identifier so a conversation can be attributed to you. It is switched off unless a support identifier is configured, and it never loads on the in-context editor, the embed surfaces, the API or the delivery endpoints. The Subprocessors document sets out the category and what the provider receives, and the named vendor list is furnished on request under a non-disclosure agreement.

Google Analytics. The value in it is a randomly generated identifier for the browser: no name, no email address, no account, and nothing you typed. Its whole job is to let a reader who comes back be counted as one person rather than two, so that a page view figure means something. Set by the Google Analytics script as a first party cookie with a lifetime of 2 years, readable by page scripts and therefore not HttpOnly, and not encrypted. Like the referral cookie it is scoped across our subdomains, so one browser carries one identifier on both the website and the app. On the website property Google Signals is switched on, which means Google may join that identifier with the account of a reader who is signed in to Google and has ads personalisation turned on in their own Google settings, and use the result to build a remarketing audience. On the product property it is switched off, so no such join happens to anything you do inside your workspace. Blocking the cookie costs you nothing: every feature works without it.

Google Analytics again, and one of these exists for each property. It holds the state of the visit you are in, such as when it started and how many you have made, which is what groups a run of page views into a single session. Set by the same script, first party, 2 years, readable by page scripts, not encrypted. We run two properties, one for this website and one for the product, and we keep them apart on purpose: the two hosts serve different people asking different questions, and merging them would make every figure on both a blend of the two. A browser that has seen both therefore carries two of these. Everything said above about what these cookies do not hold applies here as well.

The conversion linker. Google Ads writes it the first time the tag runs, and it holds a randomly generated identifier for the browser that lets a conversion recorded on one page be joined to the ad click recorded on another. Google’s script sets it as a first party cookie at transglot.ai rather than at each host, and that is the whole point of it: the ad is clicked on the website and the account is created in the product, so a cookie readable on only one of them would leave every signup looking like it arrived from nowhere. Lifetime 90 days, readable by page scripts and therefore not HttpOnly, not encrypted. It is not written while consent is denied.

Written only when you arrive from a Google ad, and it holds the click identifier from that ad so that a conversion you make later is attributed to it. Set by the same Google script, first party, 90 days, readable by page scripts, not encrypted. It is the browser half of what our own tg_ads cookie keeps on the server, and both exist because a conversion can be finished with the browser present or long after it has gone. It is not written while consent is denied.

No social network pixels or share-button trackers. No fingerprinting. No cookie from a data broker, and no sale of your browsing to anyone. No advertising audience built out of what you do inside the product: on the product property Google Signals and ad personalisation are both switched off, which is what keeps product usage a count of conversions rather than a profile of a customer. On this website they are on, and the entries above say which cookies carry it. Payment is taken on our payment processor’s own pages rather than on ours, so their payment scripts do not run here. Our delivery endpoint sets no cookie at all, which is deliberate: a public bundle URL that carried a cookie would be a tracking surface hidden inside a product feature.

Every browser can block or delete cookies and clear local storage in its settings, usually per site, and every browser has a private window that discards both when you close it. Blocking the strictly necessary cookies will stop sign in and every form from working, which is a limitation of how the web works rather than a choice we made. Blocking the preference cookies costs you the theme and the sidebar state. Blocking or deleting the referral cookie costs you nothing and costs a partner their attribution. Deleting the consent cookie makes the banner ask again. Deleting the advertising cookies costs you nothing and costs us the ability to tell which ad brought you, which is the whole of what they do. Browser extensions that block third party scripts will stop the support messenger and the Google tag from loading, and nothing else here depends on either.

We update this document whenever we add, remove or change a cookie, and we change the effective date at the top when we do. Because the list above names each cookie exactly, a change here is a real change to the product rather than a rewording. Questions go to privacy@transglot.ai.