You spend a year writing a book, then send the whole manuscript as an email attachment to a dozen strangers from a Facebook group. That's the moment most leaks happen — not because beta readers are malicious, but because a forwarded email or a shared Google Doc link has no expiry, no password, and no way to shut it off once it's out. If you want to share manuscript safely with beta readers, the fix isn't finding more trustworthy readers. It's using a sharing method that stays under your control the whole time.
Here's what that actually looks like in practice, and which controls matter most.
Why "just email the Word doc" is the risky option
A Word or PDF file sent by email has three problems once it leaves your outbox. First, you can't limit how long the recipient can access it — they can reread it, forward it, or upload it somewhere a year from now and you'd never know. Second, there's no gate on entry; anyone with the link (or the file itself) can open it, including whoever that beta reader forwards it to "just to get a second opinion." Third, and most importantly, you have no kill switch. If a reader ghosts you, or you get a bad feeling about someone, there's no way to pull the file back.
None of this means your beta readers are out to steal your book. Piracy of unpublished manuscripts is rare. But accidental spread is common — a reader saves the file to a shared laptop, syncs it to a cloud folder with lax sharing settings, or leaves it in an inbox that later gets breached. The goal isn't paranoia. It's reducing the number of ways a private draft can end up somewhere you didn't intend.
Set an expiry date on every share
The simplest control is time. Beta reads have a natural lifespan — most readers finish a novel-length manuscript in two to six weeks, especially with a deadline attached. Once that window closes, there's no reason the link should still work.
An expiry date does two things. It gives readers a gentle nudge to actually finish and submit feedback instead of letting the file sit untouched for months. And it caps your exposure automatically, so you're not relying on your own memory to go back and revoke every link you've ever sent. If you're sharing with ten readers across two rounds of feedback, that's ten links to track manually — an expiry means you don't have to.
A good default is your expected reading window plus a one-week buffer. If you ask readers to return notes in three weeks, set the link to expire in four.
Add a passphrase, especially for group shares
An expiry date limits how long a link works. A passphrase limits who can use it while it's live. The two aren't redundant — they solve different problems.
Passphrases matter most when a link could plausibly end up somewhere public: a shared beta-reader Discord, a forum thread, a group chat where you don't personally know everyone. Even a well-meaning reader might paste the link into a "hey check this out" message without thinking, and suddenly it's visible to people you never vetted. A passphrase means the link alone isn't enough — you send it through one channel (email, DM) and the passphrase through another, so a leaked link is just a dead end.
For a tight circle of five readers you already know personally, a passphrase can feel like overkill, and that's a fair call. For a larger open call for beta readers, or anyone recruited from a public group, treat it as close to mandatory.
Keep passphrases separate from the link
Sending the link and passphrase in the same email defeats the point — if that email gets forwarded, both travel together. Send the passphrase in a follow-up message, a text, or verbally if you're already talking to the reader.
Revoke access the moment you need to
Expiry dates handle the readers who are slow. Revocation handles everyone else — the reader who stops responding, the one who asks a question that makes you uneasy, or the simple case of "I've got enough feedback now, I don't need this link live anymore."
The value of revocation is that it doesn't require you to predict anything in advance. You don't need to guess the right expiry date for every situation if you can just turn a link off the instant it's no longer needed. Treat it as a normal part of closing out a beta round: once you've collected and read the feedback from a given reader, kill their link rather than leaving it dangling.
This is also the right response to gut feelings. If a reader's messages feel off, or you spot the same paragraph quoted somewhere you didn't expect, you don't need proof of wrongdoing to revoke access. Cutting it off costs you nothing and protects the rest of your readers' access too, since each share can be tied to one person rather than one link everyone uses.
Give each reader their own link
This is the control that makes the other three actually work. If ten beta readers all use the same shared link, you can't revoke one person without cutting off the other nine, and you can't tell who a leaked passage came from. Individual links solve both problems: revoke one reader without touching the rest, and if something does leak, you have a much shorter list of possible sources.
Per-reader links also let you tailor comment permissions. Some readers you want typing inline notes as they go; others you'd rather just get a completed form or email at the end. Keeping shares separate makes that flexible instead of all-or-nothing.
Pendrilo's beta-reader sharing builds these controls in directly: each share is a read-only link you can set to expire, optionally protect with a passphrase, and revoke individually, with comment permissions toggled per share and each reader's feedback returned separately as inline editor comments rather than mixed into one shared document. If you're currently juggling this with email attachments and a spreadsheet of who has what, signup for Pendrilo to see the workflow with your next beta round.
A few habits that help regardless of tooling
Even with good link controls, some low-effort habits reduce risk further.
- Watermark lightly. A footer noting "Beta draft — not for distribution — [reader name]" on each copy makes it obvious where a leaked excerpt came from, without cluttering the reading experience.
- Don't send final-looking files. A beta draft with placeholder chapter numbers or a visible "draft" watermark is less attractive to redistribute than something that looks retail-ready.
- Stagger your rounds. Sending to five readers this week and five next week means you're never managing more than one batch of active links at a time.
- Ask readers to confirm receipt and deletion. A simple "let me know when you're done and I'll close the link" sets an expectation without being adversarial.
Keep the rest of your launch prep just as tidy
Manuscript security is one piece of a bigger pre-launch checklist — cover files, keyword slots, royalty math. If you haven't run your numbers yet, the free KDP tools at Pendrilo cover royalty estimates, cover sizing, and keyword byte limits, so you can knock those out alongside locking down your beta round.
None of this requires expensive software or a security background. Set a reasonable expiry, add a passphrase when the audience is wide, give each reader their own link, and revoke anything you no longer need live. That's the whole system — and it's enough to turn "I hope nobody forwards this" into something you don't have to think about at all.
