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 profile is encrypted on your device before it ever touches our servers — we can’t read it. 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 before it ever touches our servers — we can’t read it.
  • • 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. PDFs and filled values never leave your browser. Your profile is encrypted locally before syncing to our servers as ciphertext we can’t read.

PDFs

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

Profile

Name, address, signature, custom fields — encrypted with AES-256-GCM in your browser before anything touches our servers. We store only the ciphertext; the key derives from your account and never leaves your browser. The optional Chrome extension keeps a read-through cache of the same encrypted profile so autofill works offline.

Filled values

When the local pattern dictionary matches a field (80–90% of the time), the answer is resolved client-side. Your value is read from the encrypted profile and written into the field locally — the AI is not consulted, and the only network call is a credit-spend request that carries field labels, never your values.

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

The local pattern dictionary resolves 80–90% of fields in your browser. Every fill still posts one credit-spend request to our server, and only unusual labels are forwarded to the AI provider. Here’s the exact split of what that request carries:

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
Encrypted profile ciphertext (we can't decrypt it)Multi-device sync — the key never leaves your browser
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
Anonymous error reports (stack traces, no profile data)Crash diagnostics so we can fix bugs

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. Four ways to confirm everything on this page is true.

Watch your network tab (PDF fills)

On a PDF fill in the web app, open DevTools → Network and click Fill. You'll see one POST to /fields-map — that's the credit-spend call. Web-form fills run inside the extension, so the same request is visible in the extension's service-worker DevTools rather than the page's Network tab.

Inspect the request body

Click that POST and open the payload. You'll see field labels, tooltips, and HTML attributes only — never anything from your encrypted profile. The local dictionary resolves the common labels client-side; the request still goes through so we can deduct exactly one credit per fill, server-side.

Inspect storage in DevTools

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

Clear your browser data

Clear your browser's site data and your local cache is gone. Log back in and your encrypted profile syncs from the server — proving the server only stores ciphertext it can't read (the key was in your browser, derived from your account on login).

Honest limits

The boundary of what we can defend

Local encryption defends your profile at rest and in transit, but it can’t outrun whatever runs alongside your browser. If software with your user privileges is active in the same browser session, it sees the same things your browser sees — that’s true of every local-encryption tool, not a FillDef-specific gap. Browser sync extends that boundary to any other machine you sync to, by your choice.

The device is yours to defend. What we canpromise is that the only things that leave your browser are encrypted ciphertext (which we can’t read) and field labels (which carry no personal data).

Privacy questions

What does "AI sees only labels" mean in practice?
Every fill sends one request to our /fields-map endpoint — that's how we deduct exactly one credit, server-side. The request body carries field labels, tooltips, and HTML attributes only, never your profile values. For common labels ("Email", "Phone number", "Date of birth") the local pattern dictionary has already resolved the answer in your browser. For unusual labels ("Steueridentifikationsnummer", "Mother's maiden surname") the AI provider receives only the label string and returns a profile-key suggestion like "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?
AES-256-GCM keeps your profile unreadable at rest, so a stolen laptop with the browser closed reveals nothing. The honest scope: anything running with your user privileges in the same browser session can read what your browser can read — that's a boundary every local-encryption tool shares, not a FillDef-specific gap. We defend the network, the infrastructure, and the data on disk; the device itself stays your responsibility.
Is the encryption key on your servers?
No. The key is derived in your browser via PBKDF2 and stays in browser memory — it is never transmitted to us. Your encrypted profile is synced to our servers as ciphertext for multi-device access, but the key never leaves your browser. We see the blob; we can't open it.
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.

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