FillDef homeFillDef
Defense-first

Privacy isn’t a policy.
It’s how we built it.

Most “privacy-first” tools are policy promises. FillDef is architecture: your data is encrypted on your device, our AI only sees field labels, and every request is auditable in your browser. Verify everything below.

The 30-second version
  • Your profile is encrypted on your device, not on our servers.
  • Our AI only sees field labels — for example, “Tax ID” — never your values.
  • PDFs are filled in your browser. They never reach us.

Where your data goes

The whole architecture in one picture. Solid lines stay on your device. The dashed line is the only thing that ever crosses the network — and it carries labels, not values.

Encrypted profile
On your device
label only
AI proxy
Field labels only
profile key
Filled field
Written in your browser
Your device
Network

What stays on your device

Three categories. None of them ever touches our servers.

Profile

Name, address, signature, custom fields — encrypted with AES-256-GCM in your browser or extension. The key derives from your account; we never store it.

PDFs

Fillable PDFs are read, filled, and downloaded entirely inside your browser. The bytes never reach a server — ours or anyone else's.

Filled values

When the local pattern dictionary matches a field (80–90% of the time), no network call happens at all. The value is read from your encrypted profile and written into the field, locally.

What we send to AI — and what we don’t

The local pattern dictionary handles 80–90% of fields with no network call. The remaining unusual labels go to AI, with this exact split:

We send
  • Field label string
    "Steueridentifikationsnummer"
  • Tooltip / placeholder text (if present)
    "Format: 11 digits"
  • HTML field name attribute (if present)
    "tax_id_de"
We never send
  • Your tax ID, name, address, phone, email, signature, or any profile value
  • The page URL or domain you're filling on
  • The filled output (we don't see what got written)
  • Your IP address (relayed to our server for authentication only)

The AI returns a profile key like tax_id. FillDef then reads that key from your encrypted profile in your browser and writes the value into the form locally. The AI never sees the value.

What we store on our servers

The complete list. If it isn’t below, we don’t have it.

We storeWhy
Email addressAccount login + receipts
Credit balanceSo you can spend credits across devices
Purchase historyRequired for tax + refund handling
Fill counts (numbers only, never values)Free-tier accounting + abuse prevention

No form contents, no values, no URLs you fill on, no behavioral telemetry.

What we don’t do

Track your browsing or build a behavioral profile
Sell or share data with advertisers or data brokers
Run analytics on your form contents
Log the URLs you fill on or the values you submit

We sell credits. That’s the whole business. There’s no second product made out of your data because we don’t have your data.

Verify it yourself

Don’t take our word for it. Three ways to confirm everything on this page is true.

Watch your network tab

Open DevTools → Network when you click Fill. You'll see one POST to /fields-map only when the local dictionary misses — and the body has labels, not values.

Inspect the request body

Click that POST request and open the payload. You'll see field labels and HTML attributes — and nothing from your encrypted profile.

Inspect storage in DevTools

Application → Storage shows your profile blob is unreadable ciphertext. The key isn't there because the key never leaves memory.

Honest limits

The boundary of what we can defend

Defense-in-depth has limits, and pretending otherwise is its own dishonesty. FillDef encrypts your profile and keeps it local — but if your computer is compromised, an attacker with local access can read what your browser can read. The same goes for browser sync if you’ve enabled it across machines.

We can’t defend the device itself; that’s still your job. What we can promise is that no data leaves the device unless you decide it does — and the only thing that ever does is a field label.

Privacy questions

What does "AI sees only labels" mean in practice?
When you fill a form, FillDef's local pattern dictionary tries first. It handles common labels like "Email", "Phone number", "Date of birth" entirely on your device — no network call. If a label is unusual ("Steueridentifikationsnummer", "Mother's maiden surname"), only the label string is sent to our AI proxy, which returns a profile-key suggestion such as "tax_id". FillDef then reads that key from your encrypted local profile and writes the value into the field — all in your browser. The AI never sees the value.
What if my computer is compromised?
Honest answer: we can't help. AES-256-GCM protects your profile at rest in the browser, but if an attacker has local access to your device — or to a browser sync that includes it — they can read what your browser can read. We defend the network and our infrastructure; the device itself is still your responsibility.
Is the encryption key on your servers?
No. The key is derived locally on your device via PBKDF2 from your account ID. We can authenticate you, but we can't decrypt your profile — the key never leaves your device.
Do you log IP addresses?
Our server logs requests at the platform level, the way every server does. We don't query those logs to profile users, and we don't sell or share them. We can disclose under valid legal process — that's true of any server on the internet. Specific sub-processors are named in the privacy policy.
Why is this page different from your privacy policy?
This page explains the architecture — the part that makes our claims technically true. The legal privacy policy covers compliance text required by GDPR, CCPA, and your jurisdiction. They're complementary; if anything in either disagrees, the legal policy governs.

Try it. See for yourself.

Five fills are free every month. Open DevTools, watch the network tab, fill a form — and decide.

Looking for the legal privacy policy? It’s here.