← All posts

My PDF file is 0 bytes — what now?

The file is there in the folder. Right name, right icon, roughly the right date. Size: 0 bytes. Every reader you try says the same unhelpful thing — cannot be opened, damaged, not a supported format.

So you searched, and the first three results were pages offering to repair a corrupt PDF. One of them will happily accept the file, spin for a while, and sell you a licence before telling you the result.

None of them can help, and it is worth thirty seconds to understand why, because the same thirty seconds tells you where the document actually might be.

Zero bytes means a name and nothing else

A file is two separate things on disk. There is the directory entry — the name, the timestamp, the permissions, the recorded length — and there are the blocks holding the content. Creating the entry and writing the content are different operations, and they happen at different moments.

A zero-byte file is an entry with no blocks. Not damaged content: no content. Whatever program you point at it is looking at nothing at all.

This matters because of how PDF repair actually works. A PDF is unusually recoverable for a binary format, and the reason is redundancy. The cross-reference table at the end says where every object lives, but the objects themselves are also sitting in the file, each one labelled with its own number, in plain view. When a PDF "will not open", it is almost always the table that is wrong — the offsets point at the wrong bytes after a bad transfer or a sloppy edit. A repair tool ignores the table completely, walks the file looking for object headers, finds the page tree among them and builds a fresh index from what it found.

That whole technique depends on there being bytes to walk. With zero of them there is no header, no object, no page tree, nothing to be redundant with. This is not a limitation of one tool. It is the same for every repair tool that exists, ours included.

The recovery-software pages that rank for this question blur two different words, and the difference is the entire answer:

Only the second one has any chance here, and it is not a PDF operation at all.

How a file ends up as a name with no content

Worth knowing which of these happened to you, because it changes where you look next.

A save that truncated first and then died. This is the common one. Many programs save over an existing file by opening it in truncate mode: the length is set to zero immediately, then the new bytes are written, then the handle closes. Between the first step and the last, the file genuinely is zero bytes — and the old content has already been released. If the process is force-quit, the machine sleeps oddly, the disk fills, or a mapped network drive drops out during that window, that is exactly where you are left. Careful applications avoid this by writing a temporary file and then renaming it over the original, because a rename is atomic and the old file survives until the new one is complete. Not every application is careful.

A power cut, with the metadata ahead of the data. Journalling filesystems record the change to the directory entry before the content reaches the platter — ext4's delayed allocation can hold the data in memory for tens of seconds while the new size is already durable. Pull the plug in that window and you get a file with a length and no content: zero bytes, or the right length full of zero bytes, which amounts to the same thing.

A cloud placeholder that was never hydrated. OneDrive Files On-Demand, Dropbox and iCloud all store a stub locally and fetch the real content when something opens the file. Anything that copies the file without opening it properly — a backup script, a zip utility, a drag while offline — can copy the stub. The original is fine; the copy is empty.

A download or export that produced nothing. The browser creates the file when the response starts and the connection drops before any body arrives. Or a portal answers a stale session with a polite 200 and an empty response, and you get a correctly named PDF containing it. Print-to-PDF and headless exporters do the same thing when they fail after creating the output path.

Something emptied it in place. Antivirus and data-loss-prevention agents sometimes null a file rather than deleting it, so the name stays and the content goes.

The thread running through all of these: the name gets written first, because the name is cheap. Your document was never in this file.

First, make sure it really is zero

Two false alarms are common enough to check before you do anything drastic.

Windows Explorer rounds up — any file with at least one byte in it shows as 1 KB. If it shows 0 KB, open Properties and read the exact byte count. Finder says "Zero bytes" and means it. But in a sync folder, "Size: 4.2 MB, Size on disk: 0 bytes" is a placeholder, not damage: right-click and choose always keep on this device, then wait for it to come down.

The other false alarm is the file that has a plausible size and is still empty in the way that matters — the right length, every byte a zero, courtesy of the power-cut case above. A real PDF starts with the eight characters %PDF-1. and a version digit. Check it:

head -c 16 yourfile.pdf | xxd

On Windows, certutil -dump yourfile.pdf will tell you plainly that it is not a PDF, or open it in Notepad and look at the first line.

Our PDF inspector does the same job without a terminal. It reads the file in your browser — nothing is uploaded, which is the point when the file may be the only copy left — and tells you whether there is a parseable document in there, how many pages, what the title says and when it was made. That last part is the useful bit later, when you have pulled a candidate file out of a backup and want to know if it is the version you wanted before you rely on it.

While you are looking at sizes: small does not mean broken. A 200-page text document at 900 KB is completely normal, because a PDF's size is mostly about what kind of thing is inside it rather than how many pages there are.

When there really is something to repair

The check above sometimes finds the opposite of nothing: a header, some readable bytes, a file that is short rather than empty. That is what a download that stopped half way looks like, and it is genuinely different territory — a rebuild is the right move, not a search for a backup. That is the case Repair PDF exists for: it imports every page it can actually read into a brand-new document, writes a fresh cross-reference table around them, and names the pages that were not there in its notes. A truncated file typically gives back the pages that arrived and stops.

Two things it will not do, said plainly so you do not spend an evening on them:

Where the document may actually still exist

If the check above really did show nothing — no header, no bytes, nothing for a rebuild to work with — the document has to be found somewhere other than this file. In this order. The first two solve most cases in under five minutes, and people skip them to go straight to the fifth.

  1. Re-export it from whatever made it. The Word document, the spreadsheet, the design file, the scanner's own folder, the accounting system that generated the invoice. A PDF is nearly always a render of something else, and that something else is usually untouched.
  2. Version history in your cloud storage. This is the big one, and it survives exactly this failure, because an empty save is simply the newest version and the previous ones are still listed. In Google Drive, right-click the file and choose file information, then manage versions — binary uploads keep prior versions for 30 days or 100 versions. In OneDrive and SharePoint, right-click and choose version history, which works on any file type, not just Office ones. In Dropbox it is under the file's menu, 30 days on the free and Plus plans and longer on paid ones.
  3. Local snapshots. On macOS, Time Machine keeps snapshots on the internal disk even when no backup drive is attached — run tmutil listlocalsnapshots / to see if any cover the right day, then enter Time Machine and browse the folder. On Windows, the Previous Versions tab on the containing folder shows anything File History or a restore point captured.
  4. Everywhere else a copy went. Your sent mail, the chat where you shared it, the phone that scanned it, the recipient who already has it, the temp folder of the machine that made it.
  5. Undelete, as a last resort. Truncation frees the old blocks but does not scrub them, so the previous version's bytes usually sit in free space until something else claims them. A carver scans raw sectors for the %PDF- signature and the %%EOF marker and reassembles what it finds. PhotoRec is free, runs on Windows, macOS and Linux, and knows the PDF signature by default. On Windows, Microsoft's own Windows File Recovery does it from the command line: winfr C: D: /extensive /n *.pdf. Expect the results to arrive with meaningless names, and expect some of them to be fragments — this is scavenging, not restoring.

If the version you rescue from a backup turns out to be an older, protected copy, Unlock PDF will take the password off it so the rest of your tools will touch it — assuming it is a password you are entitled to have.

Making it not happen again

Two habits remove most of the causes above. Work on a local copy and move it into the sync folder when you are done, so the sync client and the application are never writing to the same file. And open what you export, straight away — a two-second check that the PDF has pages catches the empty export while the source is still on screen and re-rendering costs nothing.

A zero-byte file is not a puzzle and it is not a corrupted document. It is the filesystem telling you, accurately, that nothing was ever written. Believe it, close the repair tabs, and go and look at your version history.

Tools this post uses: