What we know about you
Last updated 25 August 2026
What changed on 25 August 2026, before anything else. This page used to say there was no Meta pixel on this site and no advertising tracker of any kind. That is no longer true. We have started advertising on Instagram and Facebook, and the pages where you browse, write and pay for a card now load Meta's pixel. It sets cookies on your device and it tells Meta that a visit happened and, if you buy, how much was spent — ₹49, ₹99, ₹129 or ₹249. The full description is in The Meta pixel below, and it is specific rather than reassuring.
The page your recipient opens has none of it.
card.html — the link you send them — loads no
pixel, no advertising script and nothing belonging to Meta.
We still cannot tell you whether they opened your card, and
we still do not want to be able to.
The rest of the short version is unchanged: there are no accounts, every card is stored only for as long as it is readable and is then deleted automatically, and our own count of how many people reach each step of making a card is still a plain anonymous total with nothing attached to it.
This page explains exactly what ChitthiBhejo collects, where it goes, and how long it stays. It is specific on purpose. If anything here is unclear, write to chitthi.bhejo.today@gmail.com and we'll explain.
We don't collect the recipient's phone number, email address, or any other way of reaching them — because we never contact them. You share the link yourself, through WhatsApp or however you like. The only thing we know about your recipient is the name you typed on the card, which is usually a first name.
This is the most important thing on this page, so it comes before the lists. It also changed recently, and in the direction of us holding more — so it is spelled out rather than quietly amended.
What changed. The ₹49 card used to be packed into its own link and never reached our server at all. That made for a very long link, and it meant anything the link touched could read the card out of the URL. Every card is now saved on our server and addressed by a short link instead. The trade is deliberate but it is a real one: we now hold a copy of a ₹49 card, where before we held nothing. In exchange the card's contents are no longer sitting in the URL itself, and the card can be deleted on request — which was previously impossible.
All four prices store the same fields. The difference between them is what you are allowed to attach: every card except the ₹49 one can carry a photo, background music or a voice note, or be sealed until a chosen moment. What gets saved is exactly this and nothing else:
That's the whole record. There is no IP address in it, no device information, no browser fingerprint, and no identifier that links one card to another card by the same person. Two cards you send a week apart are, to us, unrelated.
Every stored card is given a deletion time when it is created: 90 days after the moment it unlocks. For a card that isn't sealed, that clock starts immediately, so it is gone about 90 days after you send it. For a card sealed for two weeks, it is gone about 104 days after you send it. There is one exception, and it is longer rather than shorter: a wedding invitation is kept for 400 days instead of 90, counted the same way. An invitation is sent months before the day and a link that expired before the wedding would be useless, so that card is held for longer — which means we hold it, and whatever is in it, for longer too. It deletes itself the same way when the time comes. The deletion is done by the storage system itself rather than by a cleanup job we have to remember to run — the card is written with an expiry and it stops existing at that time whether or not anyone is watching.
While a card is sealed, the countdown page the recipient sees is not hiding the message with CSS. The server does not send the message, the photo or the voice note at all — and it does not start the music either — only the envelope's colours, the two names and the unlock time. There is nothing in the page to dig out with developer tools. The contents are handed over on the first request made after the unlock time has passed.
Payments are handled entirely by Razorpay, a licensed Indian payment gateway. Your card number, UPI ID, bank details and CVV are entered in Razorpay's own checkout and are never sent to us, seen by us, or stored by us — we could not access them if we wanted to.
What comes back to us from a successful payment is a payment reference, an order reference, and a signature we verify to confirm the payment really happened. We use those to make sure a card is only stored for someone who actually paid, and to look up a payment if you ask us for a refund. Whatever else Razorpay collects to do its job — including billing details and its own fraud checks — is held by Razorpay under its own privacy policy.
We do not send Razorpay your card's contents. The only thing attached to the order on their side is which of the two options you bought.
While you're writing, your draft is saved in your browser's own storage so a refresh or a misplaced back button doesn't lose your words. This stays on your device — it is not sent anywhere — and it is cleared when you finish the card.
You can clear both at any time through your browser's "clear site data" setting. Neither of those two is a cookie — they are local storage and session storage, which your browser keeps separately and never attaches to a request.
There are now cookies on this site, and this paragraph
used to say there were none. They are set by Meta's pixel, not
by us, and there are two of them —
_fbp and _fbc. We set no cookies of
our own: not for logins, not for preferences, not for our own
counting. See The Meta pixel.
We advertise on Instagram and Facebook. Those ads are paid for per click, and the only way to tell a click that led to somebody sending a card from a click that led nowhere is to tell Meta which visits ended in a payment. So the sender-facing pages of this site load Meta's pixel. We would rather not, and we are not going to dress it up: it is a tracker belonging to an advertising company, and it is here because the alternative is advertising blind.
Only the pages you use to make a card:
It is not on the card page — the link you send to somebody. That exclusion is the point of the next section and is written into three separate places in the code plus the site's security headers, so that it cannot be undone by accident.
We send Meta a small, fixed list of events. Each one carries the name of the event and nothing more, except the two that carry a price. In plain terms, Meta is told:
What is not in any of it: the words of your card, either name on it, the occasion, your photo, your voice note, your card's link, and your email address or phone number (we do not have those to give). Meta never receives the contents of a card. Nothing we send identifies you to us either — we cannot look up what any one person did, before or after this change.
Meta's pixel is capable of more than that on its own. Left at
its factory settings it reads the form fields and button labels
on a page and sends what it finds — which on our write page
would mean the two names and your message. We have switched that
off explicitly (the settings are called
autoConfig and smartSetup, both set to
off when the pixel starts). Every event listed above is one we
named ourselves.
What we cannot control, and will not pretend to: as with any third-party script, loading it means your browser makes requests to Meta, and those requests carry your IP address, the address of the page you are on, and your browser's user-agent string. If you are signed in to Facebook or Instagram in the same browser, those requests can also carry Meta's own cookies, which lets Meta connect the visit to your account. Once data reaches Meta it is theirs, held under Meta's privacy policy, and we have no way to reach into it. We use it to see how many sales an ad produced. Meta may use it for its own purposes, including showing you advertising elsewhere.
Two, both set by Meta's script rather than by us:
_fbp_fbcNeither cookie contains anything you typed. We do not read either of them.
All of these work, and none of them stops you sending a card — if the pixel is blocked, nothing on this site behaves any differently. We built it that way on purpose.
_fbp
and _fbc. Blocking third-party cookies does
not remove them — they are set as first-party cookies on
this domain — so use the site-data control, or block
cookies for this site outright.
The page a recipient opens carries no pixel, no advertising script and no third-party analytics of any kind. We still cannot tell you whether your card was opened, and adding the pixel did not quietly change that.
It would have been easy for it to. The card page shares the same small counting script as the rest of the site, so the careless version of this change would have loaded the pixel there too. Four separate things stop it: the script refuses to fetch the pixel on that page; the pixel will only start on a page explicitly listed as sender-facing, and the card page is not on the list; there is no event defined for a card being opened; and the site's security headers refuse to let that page talk to Meta at all, so even a mistake in all three of the others would still be blocked by the browser.
A card is a private letter. The person who receives one did not come here, did not buy anything, and never agreed to anything. Putting an advertising company inside their envelope so that we could measure an ad is not a trade we are willing to make.
Separately from the pixel, and predating it, we keep our own count of how far people get. This is the part that has always been here, it is deliberately the weakest form of measurement we could build, and it goes to our own server rather than to anybody else. There is no Google Analytics on this site, no heatmap recorder and no A/B testing tool.
The count covers each step of making a card — landing on the
site, starting to write, reaching the preview, paying, and the
recipient opening it. It is how we find out which screen is
losing people. Each step sends one message to our own server
that says nothing but the name of the step, like
preview, and we add one to a daily total. Note that
this list includes the recipient opening a card and the pixel's
list does not: this count is a number on our own server that
says a card was opened today, with no way to tell which
one or by whom, and it goes nowhere near Meta.
Because our own counting is genuinely all it is, in it there is (this paragraph is about our count, not about the pixel above):
Your browser does remember which steps it has already counted,
so that reloading a page doesn't count you twice. That is kept
in session storage under ln_seen_steps, it holds
only step names, and the browser discards it when you close the
tab.
This is a change from what this page said before, which was that we didn't know how many people visited a page. We now do, as a plain total. We chose the weakest form of it we could build — aggregate counts, no identifiers — because a profile of someone who came here to write to a person they love is not a thing we want to hold.
The only third parties involved in loading a page are:
Nobody, unless you share the link. We don't sell data, we don't share cards with advertisers or partners, and we don't read cards for interest. We would only disclose a stored card if we were legally required to by a valid order under Indian law, or if we had to look at one to answer a specific support request you sent us.
This paragraph used to add "there is nothing to sell", and that parenthesis has been removed rather than left standing: since the Meta pixel was added there is something we hand to a third party, and while it is a handful of event names and a price rather than anything from your card, a claim that nothing leaves at all would now be doing work it cannot do. The substance is unchanged — the card itself goes to nobody, and Meta never receives it.
ChitthiBhejo isn't intended for children under 13, and we don't knowingly store cards created by them. If you believe a child has sent a card and you'd like it removed, write to us and we will delete it.
Because we hold so little, most privacy requests have short answers:
Cards are served only over HTTPS. Stored cards sit behind a 16-character random address — around 95 bits of randomness, which is not guessable in any practical sense. Everything a sender or recipient types is put into the page as text rather than as markup, and photos and voice notes are checked to be genuinely images and audio before they are shown, so a tampered link can't turn a card into a script. The background music is picked from a fixed list of our own files rather than from anything stored with the card, so a tampered card cannot make a page play something from somewhere else. No system is perfectly safe, though, and the honest limit of what we can promise is in the Terms.
If this policy changes we'll update the date at the top. If a change materially affects what we store, we'll say so plainly here rather than quietly editing a sentence.
Privacy questions, deletion requests, or anything that reads wrong on this page: chitthi.bhejo.today@gmail.com.