How to send a copy of your ID without handing over more than you meant to
The situation isn’t optional, but the copy is
At some point a bank, exchange, landlord, rental car company, or age-gated platform is going to ask you to upload a photo of your passport or driver’s license. This isn’t a trick or a scam by default. A lot of it comes from real obligations these businesses have around identity verification, fraud prevention, and age checks. You often can’t opt out of the request itself.
What you can control is the copy. A photo of your ID is a flat, unencrypted, easily copied file the moment it leaves your hands. The threat model here isn’t “how do I avoid ever sharing my ID.” It’s “how do I make sure the copy I send is only useful for the one thing it was asked for, and nothing else.” That’s a solvable problem, and it doesn’t require anonymity tools or heroics. It requires knowing what’s actually on the document and what happens to a file once you hit send.
What’s actually encoded on your ID
A driver’s license or passport carries more data than the fields you’d read off it by eye. Most government IDs issued in the last fifteen years or so include a barcode or a machine-readable zone (the two lines of characters at the bottom of a passport photo page, or the PDF417 barcode on the back of a US license). That barcode typically encodes your full name, date of birth, address, document number, and sometimes height, eye color, and issuing details, all in a format a phone scanner app can read instantly.
This matters because a “copy of your ID” isn’t just a picture for a human to glance at. If the barcode is legible in your photo, anyone with a barcode-scanning app can pull structured data out of it in seconds, no matter how the rest of the image looks. Front and back photos of a license, taken together, hand over a machine-readable version of your identity, not just a visual one.
Send only what was actually asked for
Read the request literally. If a service asks you to verify your name and date of birth match your account, it doesn’t need your address or your ID number legible in the same image. Two things help here:
Redact fields that aren’t relevant to the check. Cover the barcode, the MRZ lines, and any field not needed (often the address, sometimes the ID number) with an opaque block, not a blur. Blurring can sometimes be reversed with enhancement tools depending on the blur strength and the original resolution; a solid black rectangle drawn over the text in an image editor can’t be un-drawn.
Send the lowest-resolution image that’s still legible. A phone photo at full resolution captures far more fine detail (down to printing microtext or texture that’s part of anti-counterfeiting) than a compliance team ever looks at. Downscaling before you send reduces what a scraped copy is useful for later, without making the document unreadable for its actual purpose.
Watermark it for the one use it’s for
This is the single most useful habit for this specific problem. Before sending, overlay text on the image: the recipient’s name, the date, and the stated purpose. Something like “For [Company] account verification only, 2026-08-19.”
The reason this works is mechanical, not magical. A watermarked copy is far less useful to whoever ends up holding it later, whether that’s an employee who shouldn’t have access, a third party the file gets forwarded to, or an attacker who pulls it out of a breached database. It’s harder to reuse the image to open a new account, apply for credit, or impersonate you elsewhere, because the watermark is baked into the pixels and immediately signals the copy came from somewhere else and was scoped to a specific purpose. It also gives you a paper trail: if a watermarked copy turns up somewhere it shouldn’t, you know which service it came from.
This doesn’t erase the barcode data if you left it visible, and it doesn’t stop a company that’s careless with storage. It’s one layer, not a seal.
Check how the file actually travels
Before uploading, look at the transmission method, not just the destination:
- A dedicated upload portal over HTTPS (padlock in the address bar, and ideally a known company domain, not a redirect through a link shortener) is the baseline you want. The file is encrypted in transit.
- Plain email attachments are the weakest common option. Standard email isn’t end-to-end encrypted by default, and a copy sits in your sent folder, their inbox, and any backup or archive system on both ends indefinitely unless someone deliberately deletes it.
- Third-party identity verification vendors (the company doesn’t collect your ID directly, but redirects you to a verification provider) shift the question to who that vendor is and what their retention policy says, rather than the original company’s.
If the only option offered is emailing a photo to a general inbox with no encryption mentioned anywhere, that’s worth pausing on, not because it’s automatically a scam, but because it tells you the company hasn’t thought much about how this data is handled once it arrives.
Ask where it goes after verification
A document a service is legally obligated to check once doesn’t need to sit in their systems forever. It’s reasonable to look for, or directly ask about, a retention policy: how long the image is kept, whether it’s deleted after verification completes, and whether it’s stored separately from the rest of your account data. Many privacy policies address this in a section on identity or KYC documents specifically. If you can’t find anything, asking support directly (“how long do you retain the ID I upload, and can it be deleted after verification”) is a normal question, and a company with a real answer usually gives you one.
This is about data hygiene, not legal entitlement. Whether a company is obligated to delete it, and under what rules, depends on where you and the company are and what the verification is for, which is outside the scope of what a document about sending files safely can tell you.
When there’s an alternative to uploading a static image
Some services let you verify over a live video call instead of an uploaded photo, sometimes with a staff member, sometimes through an automated liveness check where you hold the document up and move it slightly. A live check has one advantage worth noting: nothing is ever encoded as a static file that can be lifted wholesale, redistributed, or matched by a barcode scanner. Not every service offers this, and it isn’t inherently private just because it’s live. It’s simply a different tradeoff, worth taking if it’s on the table and the file-upload alternative feels excessive for what’s being verified.
What redaction and watermarking don’t do
None of this makes the underlying document untraceable, and none of it substitutes for judgment about whether the request is legitimate in the first place. A redacted, watermarked photo sent to a company running weak security still ends up in whatever breach happens to that company. No single step here, redaction, watermarking, checking for HTTPS, guarantees the copy stays contained. What it does is reduce how useful the copy is if it ends up somewhere it shouldn’t, and it gives you a way to tell your copy apart from anyone else’s if it does.
The habit worth keeping is simple: before you send a photo of a government ID anywhere, ask what’s actually needed, black out what isn’t, put a purpose and date on the image, and check that it’s traveling over an encrypted connection instead of a plain attachment. That’s the whole practice. It won’t make the document invisible. It’ll make the copy you sent worth a lot less to anyone it wasn’t meant for.
If you want more of this kind of practical, threat-model-first look at everyday privacy decisions, come find the rest of what we cover at The Privacy Wire.