How We Built Screenshot Import — Without Ever Seeing Your Screenshot

Most import tools send your image to a server. Ours doesn't. Here's exactly what happens — and why we built it this way.

When you upload a screenshot to most apps, it travels to a server somewhere, gets processed by software running on someone else's computer, and — if you're lucky — gets deleted afterward. You're trusting a company's promise. With CycleVault's screenshot import, your image never goes anywhere. It's read entirely inside your browser, on your device, by open-source software. Here's how that actually works.

Why we built it differently

When we started thinking about data migration, the obvious approach was the one everyone else uses — upload the screenshot to a server, run OCR (optical character recognition) on it in the cloud, return the extracted dates, delete the image. Fast, accurate, easy to build.

We didn't build that. Here's why.

A screenshot of your period tracking calendar is one of the most intimate images a person can upload to a service. It contains months or years of health history — cycle dates, symptom logs, fertility windows, pregnancy attempts. Sending that to a server, even briefly, even with deletion promises, creates a window of exposure that contradicts everything CycleVault stands for.

"Your data never leaves your device" can't have an asterisk next to it. So we found a way to make import work without one.

The good news: we didn't have to compromise. Browser technology has advanced to the point where serious image processing can happen entirely on-device. Your browser is more capable than most people realise.

What other import tools do

To understand why on-device processing matters, it helps to see what the standard approach looks like:

The difference isn't a matter of degree — it's architectural. One approach requires trusting a company. The other requires trusting only your own device.

The technology: Tesseract.js

The tool that makes this possible is called Tesseract.js — an open-source OCR (optical character recognition) engine that runs directly inside a web browser.

Tesseract was originally developed at HP Labs in the 1980s, later open-sourced by Google, and has been maintained by the open-source community ever since. It's one of the most widely used and audited OCR engines in the world. The JavaScript version — Tesseract.js — uses WebAssembly to run the same engine natively in any modern browser without any server involvement.

Tesseract.js is open-source, meaning anyone can inspect exactly what it does. It is not our software — we don't control it and we didn't build it. That's actually a feature: open-source tools can be independently verified. You don't have to trust our word about what happens to your image. The code is public.

What happens when you upload a screenshot

Here is the exact sequence of events when you use CycleVault's screenshot import — nothing more, nothing less:

Step-by-step: on-device screenshot import

The privacy guarantee in code

Privacy claims are easy to make. We want to show you the actual implementation principle — the moment the screenshot is cleared after OCR completes:

// Load image into browser memory for OCR
const imageData = loadImageFromFile(userSelectedFile);

// Supports 12+ languages — no network request made
// during this step. Language packs load locally in
// the browser, not from any server
const result = await Tesseract.recognize(imageData, 'eng+hun+deu+fra+spa+ita+nld+pol+swe+nor+dan+fin');
const extractedText = result.data.text;

// Screenshot cleared from memory immediately after OCR
// It is never written to localStorage, sessionStorage,
// or any persistent storage — only text remains
imageData = null;

// Parse dates from extracted text only
const foundDates = extractDatesFromText(extractedText);

// Show dates to user for review — nothing saved yet
showConfirmationScreen(foundDates);

The key line is imageData = null — the image reference is released immediately after OCR, before the confirmation screen ever appears. The screenshot is gone by the time you're reviewing your dates.

How this compares to other trackers

Being honest about the limitations

On-device OCR is genuinely impressive, but it isn't magic. Tesseract.js is highly accurate on clear, standard screenshots — but there are cases where it struggles:

• Low-resolution screenshots — if the image is small or blurry, text recognition accuracy drops. Take the screenshot at full resolution if possible.
• Unusual fonts or calendar layouts — most period apps use standard date formats, but decorative fonts can confuse OCR engines.
• Dark mode screenshots — light text on dark backgrounds can be harder to read. Try exporting a light-mode screenshot if available.
• Processing speed — on-device OCR uses your device's processor. On older devices this may take a few seconds longer than cloud processing.
• Symptoms and mood are not extracted — screenshot import reads dates only. For full history including symptoms and mood, use the CSV import.

Why this matters beyond CycleVault

The approach we've described here — on-device processing using open-source tools, no server involvement, mandatory user review before data is committed — isn't just a CycleVault choice. It's a template for how health apps should handle sensitive data.

The industry assumption has been that useful features require data to leave the device. Screenshot import seemed like a feature that proved this — surely you need a server for OCR. Tesseract.js demonstrates that assumption is wrong. Meaningful processing can happen locally. Trust doesn't have to be delegated to infrastructure you can't see.

We hope other apps take notice. Your health data deserves better than "we promise we deleted it."