Data, Privacy, and Saved Chart Links Explained

The free birth chart is computed by JavaScript running in your browser. Your birth date, time and city are read out of the form, converted to a UTC instant, handed to an ephemeris already sitting in the page, and drawn — with no request to our server anywhere in that sequence. Since August 2026 they are not written into the address bar either, and a link you choose to share puts them after a # rather than a ?, which is the difference between a string browsers transmit and one they never do. This page sets out the parts people actually worry about: what the saved-chart feature keeps, what pressing Copy link to this chart hands over, what the offline cache will and will not write to disk, what the paid report does differently, and what advertising can see. It also names the things that genuinely are transmitted, because a privacy page that claims nothing leaves your device is lying about the ad requests.

The free chart is computed on the machine you typed it on

The calculator is one script. It reads the date field, the time field and the city you picked, converts your wall-clock birth time to UTC through that city's own time zone, computes ten bodies and — if you gave a time — the ascendant, and writes the result into the page. Nothing in that path is a network request: not fetching positions, not looking up the city, not logging the attempt. The ephemeris and the city list are static files the page already loaded. The full pipeline, and the two reasons for it that are not about privacy, are on how Zodiux calculates a birth chart.

The compatibility calculator is stricter still. It holds two people's birth details, computes both charts and their cross-aspects in the page, and writes no storage key and no URL parameter. One request does leave when you press the button, and it is not about the charts: a four-field counter ping recording that a compatibility check happened — the event name, the page path, the referring domain, and an empty slot. Neither person's details are in it. What survives on our side is one number per day — how many checks ran, not who ran them, and not what was in them. Close the tab and both charts are gone with it.

The page does make requests, and none of them carries your chart. It loads its scripts, the font stylesheet and the ad frames the way any page loads assets. It posts to our own server in four cases, and two of them are automatic: a pageview beacon when the page loads, and the same beacon again with a different label when you press one of four buttons — calculate a chart, check compatibility, join the Cusp+ list, start a report. Both carry the path and never the query string. The other two are things you did deliberately: submitting the Cusp+ launch form, and starting a paid report checkout.

Why your birth details are not in the address bar

Until August 2026 the calculator wrote your inputs into the URL after computing — the page you were looking at was zodiux.io/?d=1990-04-12&t=07:45&c=Lisbon, Portugal. Nothing was transmitted to us by that. But a URL is not private storage, and it leaked in four ordinary ways.

The inbound half, closed at the edge

Stopping the calculator from writing the URL fixed only the outbound half. Someone else's shared link still arrived as a URL carrying your friend's birth details, on the page that loads the ad tag. So the edge worker now prepends one script to the very top of every page's head — before the ad tag is parsed, before any other script runs. It lifts d, t and c into memory, then rewrites the address bar without them. The calculator hydrates from memory instead of from the URL. Any other parameter is left alone.

That is why a link from before the change still works, and still ends up with a clean address bar on arrival.

The four routes a URL leaks by

• Browser history. A visited URL is written to history, surfaces in the address-bar dropdown of anyone who later types 'zod', and on a signed-in browser syncs to every other device on that account. The current URL is just the page path, so history records that you used a calculator, not what you put into it.
• Screenshots and screen shares. People screenshot their chart. The address bar is usually in frame. It no longer has anything in it to read.
• The ad request context. This is the one that actually mattered. Our Referrer-Policy is strict-origin-when-cross-origin, so a cross-origin request only ever carried the bare origin, never the path or query. But the ad script does not need a referrer — it runs inside the page and reads the page's own location. A policy about referrers cannot reach that, and the calculator is one of the pages carrying the ad tag.
• On-disk caches. A URL with a query string is a cache key. The browser's HTTP cache and the service worker's Cache Storage can both hold it long after the tab closes, somewhere no button in our interface could reach.

One consequence is worth stating plainly rather than burying: this changed what is default, not what is possible. The parameters still exist and can still be put into a link. The difference is that doing so is now an act, not a side effect.

What “Copy link to this chart” actually makes

The button sits under your rendered chart, between Download chart (free) and Order as a print. Its tooltip says what it makes: a link containing your birth date, time and city. That is the whole feature, and it is the only thing on the site that turns your birth details into a URL you can hand to somebody.

Why a fragment and not a query string

The part of a URL after # is the fragment, and browsers do not put it in the HTTP request. When your recipient opens the link, our server sees a request for / and nothing else. So do the host's logs, and so does every ad and font request that page makes. A query string would have been visible to all of them; a fragment is visible only to the page itself, which is where the calculator reads it.

There is one place the hand-off is deliberately a query string: the Get my report button builds /reports/?d=…&c=…&t=…, plus the referral tag if you arrived from one of our social links. That page renders server-side, carries no ad tag, and buying a report is a transmission you are explicitly asking for. It also prefills from your device's saved chart, so the parameters are a convenience rather than the mechanism.

Step by step, when you press it

1. The page takes the parameters it kept in memory and encodes them in order — date, then city, then time.
2. It joins them to the current origin and path after a #, not a ?. For a 12 April 1990 birth at 07:45 in Lisbon the result is exactly https://zodiux.io/#d=1990-04-12&c=Lisbon%2C+Portugal&t=07%3A45 — comma encoded as %2C, space as +, colon as %3A. Nothing is added, and nothing about you beyond what you typed is included.
3. On a device with a native share sheet, it opens the share sheet with that link. Otherwise the link goes to your clipboard and the note under the buttons changes to say it contains your birth date, time and city, and to share it only with people you would tell those to. If the clipboard is blocked, the note prints the link so you can copy it by hand.
4. Nothing is sent to us at any step. The link is built on your device; whether it ever reaches anyone is your decision.

Two consequences follow, and neither is reversible by us. A link you have sent is in someone else's message history and, once opened, in their browser history. And because an inbound link makes the recipient's page compute the chart, their browser then saves it as its own last-used chart — the same device-local save described in the next section, on their machine, holding your birth details.

Everything Zodiux can store, and how to delete it

Four keys in this browser's local storage, one cache, and four kinds of record on our side. That is the complete list. Zodiux itself sets no cookie, uses no sessionStorage and no IndexedDB — the advertising cookies are a separate matter, further down. Every device-side item lives under this site's own origin, so clearing site data for zodiux.io removes all five in one action.

The saved chart deserves one clarification, because it surprises people. It exists so a returning visitor lands back on their own chart instead of an empty form, and the banner that appears says exactly that: this is the chart you saved on this device. Pressing Start over deletes the stored entry, empties the three form fields and clears the result in the same click.

What the offline cache keeps, and the one thing it refuses

Zodiux installs a service worker so the site still opens on a bad connection. One line on the homepage registers it, and from there it controls the whole origin.

It is deliberately narrow: GET requests only, this origin only, and network-first — an online visitor always gets the live page, and the cache is only ever the fallback for a request that failed. It ignores /api/ entirely so anything dynamic stays live, and ignores /media/ because multi-megabyte range requests do not belong in a page cache. At install it stores five files: the homepage, the offline page, the stylesheet, the favicon and the web manifest.

Then the refusal. Before writing any response to Cache Storage, the worker checks whether the URL carries a d, t or c parameter — the three that would be a person's birth date, time and city — and if it does, the response is served and thrown away rather than stored. A cache entry outlives the tab, and nothing in our interface could reach in and clear it. The check is on those exact parameter names, so a versioned asset URL like /styles.css?v=7 still caches normally.

Its scope is worth stating honestly rather than overselling. Today's share links are fragments, and a fragment never reaches the service worker at all — it is not part of the request URL and not part of the cache key, so there is nothing there to refuse. The check is doing its work on the legacy query-string links still sitting in people's message histories, and on anything that puts those parameters back. It is a second lock, not the main one.

What ads and measurement can see

Two separate systems, and they are not equally invasive. Being clear about which is which is more useful than a blanket reassurance.

Our own counter

Every page carries a small first-party beacon, injected at the edge. It POSTs four fields to /api/ev: an event name, the page path, the hostname of the page you came from, and an optional label that nothing on the site currently sets. The path, never the query string — and since inbound parameters are stripped from the URL before this runs, there would be nothing of yours in it either way.

What the server keeps is smaller than what it receives. It increments one number under a key made of the event name and today's date, and discards the path and the referring host. The counter is written with an expiry of 60x60x24x120 seconds — 10,368,000, or 120 days — after which it disappears on its own. No cookie and nothing written to your device. The counter itself holds no identifier — but the beacon is an API call like any other, and every API call also bumps an abuse counter keyed on your IP address, which expires two minutes after it is written. That is a rate limit rather than analytics, and it is the honest asterisk on "nothing that could identify you". Nothing in either record is joined to a person, a session or a chart, which is why the beacon runs without asking. One more thing that belongs here rather than in a footnote: the consent panel does not switch this off. What the edge parks for EEA, UK and Swiss visitors is the advertising scripts specifically — the two ad tags by name. The first-party counter is injected into every page either way, because it sets nothing on your device and identifies nobody, so there is nothing for a storage consent to govern. If you would rather it did not run at all, a tracker blocker will stop it; we would rather tell you that than let you assume Reject covered it.

Advertising

Ads are served by Google AdSense, and Google and its partners may use cookies or device identifiers to serve and measure them. We do not control that collection and will not pretend otherwise. What we control is when it starts.

For visitors in the EEA, the UK and Switzerland — 32 country codes the edge checks against the country Cloudflare reports — the ad script tags are disarmed before the page is delivered. They arrive as inert markup rather than running code, and are only turned back into scripts once a choice is recorded. Consent Mode defaults to denied there, and the page waits for your answer.

Everywhere else the default is granted and ads load as normal — but a Reject choice binds everywhere. Choose it once and every later page load runs with ad storage denied, rather than recording your answer and ignoring it.

The control, and the three pages it is missing from

Privacy choices in the footer opens the same panel, in every region, and the choice it stores applies from then on. Of the 175 pages in our sitemap it is on every one but /reports/. Three further pages that are not in the sitemap also lack it: /reports/ready/ and the Cusp+ rules page, both deliberately unindexed, and the offline fallback page, which now carries a direct link to this policy instead. Those gaps are oversights rather than policy, and the choice is stored per browser, so making it anywhere covers everywhere.

Fonts, which are a real transmission

Every page loads its two typefaces, Fraunces and Inter, from Google's font service. That is a request carrying your IP address and user agent to Google on page load, regardless of what you chose about ads, and it belongs on this list rather than in a footnote. What it does not carry is the page's path or query string: cross-origin requests, ad requests included, are sent only the bare origin as a referrer.

Everything that leaves your device, complete

A privacy page is only worth reading if it names the exceptions. Here they are, in full.

The paid report, in detail

The report is rendered on our server, so it cannot be generated without the data. What the purchase form sends is your birth date, your birth time if you have one, the city label, its latitude, longitude and time-zone name, plus your email if you chose to give one. The form states this above a checkbox you have to tick yourself, and the button refuses to proceed until you do.

Stripe receives the order id, plus your email if you gave one so the receipt can reach you. Your birth details are never put in the payment payload. Card details never reach us at all, because checkout happens on Stripe's own hosted page. If you gave an email, one more party is involved: the "your report is ready" message goes out through our mail provider, and the link in it is the only key the report needs — anyone holding that message can open the report for as long as the order lives. Leave the email blank and the link never leaves your own browser.

Retention is enforced by an expiry on the stored record, not by a promise to remember. An unpaid order is written with 3,600 seconds — one hour, so an abandoned checkout cleans itself up. A paid one is rewritten with 60x60x24x30 seconds: 2,592,000, exactly 30 days, which is the window you have to re-download it. After that the record is gone whether anyone acts or not. Sooner on request to hello@zodiux.io.

The reports page states all of this before you pay, and the privacy policy is the binding version.

On a normal visit, this is the list

• The page request itself, which reaches Cloudflare with your IP address, user agent, approximate country and a timestamp — like any request to any website.
• The pageview beacon: an event name, the path, and the referring hostname.
• Ad requests to Google, and the font-stylesheet request to Google, both of which see your IP address and user agent.
• Your email address, if you type it into the Cusp+ launch form and submit it.
• Your birth details and optional email, if you buy a paid report. This is the one case where the free-chart rule does not hold.

How to leave no trace

If you want to run a chart and have nothing survive it, this is the order that works.

Six steps, in order

1. Open a private or incognito window. Everything below still applies, but the browser will discard the storage itself when you close it.
2. Run your chart at the calculator. Nothing of it is transmitted, and the address bar stays clean.
3. Use Download chart (free) rather than Copy link. The file is the wheel — rings, aspect lines, planet glyphs and the ascendant mark. It contains no text: no date, no time, no city, no name, and the filename is the same for everyone. Be aware of what it does still carry, though, because we would rather say it than not: the drawing IS the sky at your birth moment, so someone determined enough could read the planet positions off it and work back to roughly when and where you were born. It is safe to post in the sense that nobody scrolling past learns your birthday; it is not a redaction. Share my Big 3 is safe for the same reason: the card holds three sign names and a link to the homepage, and the only chart data the page hands it is three sign numbers.
4. Do not press Copy link to this chart unless you want a specific person to have your birth details.
5. Press Start over on the welcome-back banner to delete the saved chart, or clear site data for zodiux.io in your browser settings — that removes all four storage keys and the whole page cache in one action.
6. Skip the paid report. It is the only path that sends your chart to us. If you already bought one, it expires after 30 days on its own, or email hello@zodiux.io and it goes sooner.

None of this requires an account, because there are no accounts. There is nothing to log out of and no profile holding a history of what you calculated, on our side or anyone else's.