A Redacted PDF in Google Drive or SharePoint Often Leaves the Original in Version History
Overwriting the current file is not deleting the previous bytes. Drive and SharePoint are versioned. Anyone with enough access can open an older revision and copy the unredacted PDF. Replacement is not a purge.
Cloud drives train people to think of a filename as one document. Internally it is a chain. Each replace, each “open in Google Docs and export,” each SharePoint check-in, appends a revision. When you finally burn in redaction and put that PDF back under the same name, collaborators with edit rights can open Version history and fetch Tuesday’s file — the one with the account numbers still selectable. Admins can do it after you leave the folder. Recycle bins and retention labels can keep it after you delete the visible version. The redacted “current” file is real. It is not the only file.
How to clean a PDF before it ever sits in Drive is redact a PDF before sharing on Google Drive. General public-sharing hygiene is redact a PDF before sharing online. This page is the gotcha after the file is already there: overwrite is not purge.
Google Drive: same ID, many blobs
Drive’s version history is a feature for recovery. It is a liability for redaction. If you replaced the file in place, or an editor wrote a new revision, older revisions remain until someone with permission deletes them. In the Drive UI, Version history lists dates and authors. An editor can download a prior PDF. “Anyone with the link” viewers typically see current content only — but the threat for this page is people who already had edit or who can be granted it, plus Workspace admins.
Deleting individual versions: open the file, Version history, and remove revisions you are allowed to remove. Google’s UI and permissions change; if you cannot delete a version, you do not have a purge, you have a hope. A more reliable pattern is often: create a new Drive file from the redacted PDF (new document ID), share that ID with the audience that should see only the masked copy, then stop sharing the old ID and, if policy allows, move the old object to trash and empty trash. Trashed files are still recoverable for a period. Confidentiality that requires the old bytes gone may need an admin and a retention review — Drive is not a shredder.
Copies multiply outside history too. “Make a copy,” email, “Download,” and shared-drive mirrors. Purging versions on one object does not reach a copy in someone else’s My Drive. Ask who already downloaded. That is a people problem.
SharePoint and OneDrive: library versioning, recycle, retention
A document library with versioning on (the usual default) stores major and sometimes minor versions. Replacing a PDF through the browser or sync client creates a new version; the previous remains until version limits or a person deletes it. Version history on the item shows the chain. Users with contribute/edit can often restore. Site collection admins can do more.
Deleted versions and deleted files go to recycle bins (site, then site-collection). Retention policies and eDiscovery holds can prevent permanent deletion even when the UI says empty. If the PDF was in a legal hold, “I replaced it with a redacted one” may be both incomplete and, in a litigation context, something to talk to counsel about before you start destroying versions. This page is a privacy-gotcha explanation, not a spoliation guide — if the file is evidence, preservation beats clever redaction of the working copy.
Practical purge when you are allowed to: delete excess versions from Version history, confirm versioning settings will not keep 500 copies of the next mistake, consider replacing the sharing link with a new file in a new library location, and check both recycle bins. Sync clients may still have the old PDF in a local OneDrive folder on a laptop. Those are more copies.
A sequence that does not pretend overwrite is enough
Burn in a local export
Use the tool above on a copy of the PDF. Verify search and paste fail. That file is what should become the new current version — or, better, a new object.
Prefer a new file ID when the old one was dirty
Put the redacted PDF in Drive or SharePoint as a new item. Share that item. Treat the old item as contaminated even after you “replaced” it once.
If you must keep the same URL or name, purge versions
Delete prior revisions you are allowed to delete. Confirm as an editor that you cannot restore the unredacted PDF. If you still can, the purge failed.
Check trash, sync folders, and who already downloaded
Empty recycle bins if policy allows. Look at local synced copies. Tell collaborators the old file is retired.
How HidePDF fits
HidePDF never sees your Drive. It produces the bytes that should sit in “current.” The platform work is yours: history, permissions, retention. Doing the burn-in locally still matters so the new revision is actually redacted, not a second visually painted file that still pastes text — that failure is the copy-paste page in this batch.
If the PDF has not been placed in Drive yet, start with redact a PDF before sharing on Google Drive so the first object in the cloud is already burned in. If it has, use this page’s history steps; do not skip them because the filename looks the same.
Mistakes that leave Tuesday’s PDF one click away
Putting a replacement in the same Drive object and announcing the folder is clean. Open version history yourself, as a hostile editor would.
Deleting the current file but not old versions, then restoring from history “to fix a share.” You just resurrected the secret.
Assuming viewers cannot see history. Often true for pure viewers; false for editors and admins. Your “internal only” folder is full of editors.
Ignoring OneDrive on a home PC that synced the library. The laptop still has the old PDF.
Redacting in a Google Doc comment and exporting. Comments and suggestions are not burn-in, and Docs has its own revision trail.
Related guides
Explore more ways to redact PDFs privately, or use the redaction tool above:
Frequently asked questions
If I replace the PDF in Drive with a redacted one, is the old file gone?
Usually no. Drive keeps version history on the same object. People with edit access can open Version history and download an earlier revision. Making a brand-new file (a copy with a new ID) and sharing only that copy is cleaner than overwriting — then restrict or delete the old object if policy allows.
Does SharePoint behave the same way?
SharePoint and OneDrive libraries are versioned by default in many tenants. Check-in, major/minor versions, and recycle bins all keep prior content. Site owners and administrators can often recover what a member “replaced.” Retention and eDiscovery policies can keep copies even after you delete versions.
Should I redact in HidePDF before I put the file in Drive?
Yes for the bytes you intend to share. That still does not purge versions of a file that was already in the library unredacted. Do the local burn-in first, then deal with history on the platform.
Does HidePDF connect to my Drive or SharePoint to delete versions?
No. HidePDF only processes a PDF in this browser tab. Version history lives in Google’s and Microsoft’s products. You change those in their UIs (or via an admin).