Journalists: handling confidential documents and sources privately

A source slides you a PDF. Maybe it’s an internal memo, a contract someone wasn’t supposed to keep, a scan of a document that proves the thing you’ve been chasing for months. Your job now is to read it, work with it, store it safely, and never let anything you do lead back to the person who gave it to you.

That last part is the hard one. The reporting can be solid and the story can be airtight, and a source can still get identified by a detail nobody thought about. A document property field with a username in it. A revision history. A file that quietly went up to a server you forgot was processing it. Source protection isn’t only about who you talk to. It’s about what the files themselves give away.

The upload is the leak you don’t see

Say you’ve got a leaked PDF and it arrived in three pieces, or the scans are in the wrong order, or you want to lock it before you drop it in shared storage. So you search for a free tool, drag the file in, and click the button. Most PDF sites work by sending your file to a server, doing the job there, and handing the result back.

For a holiday itinerary, fine. For a document a source risked their career to hand you, you’ve just put a copy of it on a machine owned by a company you’ve never spoken to. You don’t know where that server sits, which jurisdiction it answers to, who can be served a request for its logs, or how long the file really stays there after the cheerful “deleted after one hour” message. If that document is sensitive enough that a government or a corporate legal team wants to know who leaked it, every copy that exists outside your control is a thread someone can pull.

The file might carry the answer inside it too. PDFs store metadata: author name, the software that made it, creation and modification timestamps, sometimes the network path it was saved from. A leaked internal document can contain the login of the last person who touched it. Send that PDF to a random web tool and you’ve handed a stranger’s server a file that may already name your source.

Work on it without it leaving your laptop

The fix is simple to state. Don’t upload the document anywhere you can’t see. If the file never leaves your machine, it can’t be pulled from a server somewhere else, and it can’t sit in a backup waiting for a subpoena.

Browser-based tools make this practical. The PDF is read into memory on your own computer, the operation runs there, and the finished file saves straight back to you. Nothing is sent. Here’s how the usual handling goes.

Combine the pieces. Leaks rarely arrive tidy. You get a memo, three appendices, and a cover note as separate files. Drop them into the Merge PDF tool and you get one document you can actually work with, without mailing anything to a conversion site.

Lock it before you store it. Once you’ve got the file you need, protect it with a password before it goes into shared drives or onto a laptop that travels. The Protect PDF tool encrypts it in your browser, so the document is unreadable to anyone who gets the file but not the password. That matters if a device is seized, lost, or grabbed at a border.

Open files a source already locked. Sometimes the document comes encrypted and you have the password from your source. The Unlock PDF tool removes the protection locally so you can read and work with it, again without the file touching a server. Use this only on documents you’re authorized to open.

Strip the metadata that names people

Before you publish a document or share it with a colleague, clean what’s hidden inside it. Re-saving a PDF through a local tool rewrites the file and drops most of the embedded properties that came with the original: author fields, editing software tags, the timestamps that place a person at a desk on a particular afternoon. Open the file, run it through a browser-based operation, export the clean copy, and check the document properties to confirm the giveaway fields are gone. Do this on the version that leaves your hands, never on your only copy of the original.

Prove to yourself nothing uploaded

You don’t have to trust me that these tools stay local. Open one, press F12 for DevTools, go to the Network tab, tick “Preserve log,” and run a full operation. Watch the traffic: the page loads up front, and then nothing moves while you work. If your file never appears in the body of a request, it was never sent.

Want the harder test? Load the tool, switch to airplane mode, and do the whole job with the network off. It still works, because there was no server step to begin with. A tool that uploads will error the second you hit go. That gap is exactly what your source’s safety depends on. (If you want the legal angle on why uploads are an exposure, I wrote about the GDPR risks of uploading PDFs separately.)

Make the safe way the default

You won’t audit a privacy policy at midnight on deadline. Nobody does. So decide once: documents from sources get handled in the browser, locked before storage, and cleaned before they leave your hands. Bookmark the tools and stop sending sensitive files to servers you can’t watch. Your source trusted you with something that could cost them everything. The least the files can do is keep that trust instead of giving it away.