Ask ten dental front desks how they got the last CBCT to an oral surgeon and you will hear the whole taxonomy of workarounds: a personal email account because the office one "wouldn't take the file," a consumer share link with no BAA behind it, a burned CD handed to the patient, a thumb drive in a padded envelope. Every one of those is a HIPAA finding waiting for an audit, and every one of them exists because moving a gigabyte of imaging between two dental offices has been harder than it has any right to be.
We run send.intake.dental, a free secure file transfer service built specifically for dental offices. As of this week, every transfer sent through it is end-to-end encrypted by default — the files are encrypted inside your browser before a single byte is uploaded, and our servers only ever store ciphertext they cannot read. This post explains what that actually means, why it is different from the "HIPAA-compliant" label most tools carry, and where the honest limits are.
"Encrypted" and "we can't read it" are not the same claim
Almost every file-sharing product you have ever used says files are "encrypted in transit and at rest." That is table stakes, and it is true of practically everything — it means the connection uses TLS and the disks are encrypted. But in that model the service holds the keys: their software decrypts your x-rays every time it builds a download, generates a thumbnail, or responds to a subpoena. Encryption at rest protects you from a stolen hard drive. It does not protect you from the vendor, a compromised vendor employee, or a breach of the vendor's application layer.
End-to-end encryption is a different architecture. The encryption key is generated on the sender's device, the files are sealed before upload, and the key never travels to the service in a form it can use. The service stores — and could only ever leak — random-looking ciphertext. When the 2024–2025 wave of healthcare data breaches hit clearinghouses and imaging vendors, the difference between those two architectures was the difference between "attackers got 190 million records" and "attackers got noise."
How the encryption works, in plain language
When you drop files into send.intake.dental, your browser generates a random 256-bit AES-GCM key for that transfer and encrypts each file locally in 8 MB chunks — which is why a 4 GB CBCT export works on an ordinary front-desk computer without ever loading the whole scan into memory. Only the encrypted result is uploaded.
The key reaches your recipient two ways, and neither involves us holding it usable:
- The copy-link path: after sending, you get a link with the key tucked into the URL fragment — the part after the
#. Browsers never transmit fragments to any server, ours included. Text it or paste it into your referral chat and the key goes straight from your screen to theirs. - The emailed-link path: the email we send the recipient contains no key at all. Their copy of the key is stored wrapped — encrypted with a key derived from the 4-digit PIN you share by phone or text, hardened with 600,000 rounds of PBKDF2. Their browser unwraps it locally when they enter the PIN.
Decryption happens on the recipient's device too, including the built-in viewer: they can open DICOM x-rays, photos, and PDFs right on the download page, in their browser, without installing anything — and the pixels never exist unencrypted on our side.
What the free tool actually does
Everything below is free, with no account to create — you verify your work email with a one-time code, accept the BAA once, and send:
- Up to 10 GB per file — full CBCT exports, intraoral scan meshes, whole-case photo sets
- Two-factor access: the link goes to the recipient's email, the PIN travels out-of-band, so a compromised inbox alone opens nothing
- A built-in DICOM viewer on the receiving end — the specialist's front desk clicks Preview and sees the x-ray, no imaging software required
- Automatic expiry and deletion — transfers are purged from storage after they expire; a transfer service should never be a permanent archive
- A full audit trail — who sent what to whom, when it was opened, when it was downloaded
- A request-files flow — ask another office to send records to you, and they get a one-click link with your address pre-filled
- A signed BAA on file from first sign-in, dated and downloadable
The honest trade-off
End-to-end encryption means we cannot scan your files server-side — for malware or anything else — because we cannot see them. Non-encrypted transfers through the same service are scanned with an antivirus engine before download; end-to-end transfers are not, and the interface says so plainly rather than pretending otherwise. For files moving between two dental offices that already trust each other with a patient, that is usually the right trade. If you would rather have the server-side scan, the encryption toggle is yours to switch off per transfer.
One more piece of key hygiene: if you use the copy-link (the one with the key after the #), do not put that link and the PIN in the same message. The whole point of two channels is that intercepting one gets an attacker nothing.
Why a practice-management company gives this away
Referral friction is a dental-industry tax. GPs lose track of cases they send out, specialists chase records for half the morning, and patients repeat x-rays that already exist because the originals are stuck in someone's outbox. We build front-office automation for dental practices, and every one of those failure modes eventually lands on a front desk we are trying to automate. A free, genuinely secure transfer rail between offices makes the whole referral ecosystem work better — and if your office ends up wanting the rest of the front office automated too, you will already know where we live.
Send your first encrypted transfer at send.intake.dental — no account, no cost, up to 10 GB per file. Or read more about our HIPAA compliance posture.