Drop the file that will not open into the emerald zone below and press the button. Almost every PDF that refuses to open carries the same injury: a broken cross-reference table, which is the index at the end of the file telling a reader which byte each object starts at. The pages themselves are usually untouched. The map to them is not. So the engine ignores that index completely, walks the raw file byte by byte collecting every object it can still find, and writes a new document with an index measured from where those objects actually land. Nothing is uploaded, which is the only sensible way to handle a file you are already worried about.
Your files are read by JavaScript running on your own machine. There is no upload, no queue, and no copy on our server to delete later.
Drag a card to reorder it, or use the arrows under each card. The order here is the order in the output. Each card is a preview of the finished page, so what you see is what the PDF will contain.
Esc close ← → move R rotate
Starting
This is your processor doing the work, so the time it takes depends on your machine and not on how many other people are on the site.
The repair tool above works right now. The guide below explains what is actually broken when a PDF will not open - the six symptoms that cover nearly every case, which of them recover completely and which genuinely do not, what the engine does step by step, and how to tell a damaged file apart from one that is merely encrypted.
Under a minute, and nothing to install. This PDF repair tool runs inside the page you are reading, on your own processor. A file you are trying to recover is often the only copy of something that matters, and uploading it to a stranger at that moment is a poor instinct.
Drop it into the Repair PDF upload zone. Every other tool in this suite refuses a file it cannot parse and sends you here; this one is built for exactly that file, so a card reading "Unreadable" is what you should expect to see on this page.
Press Repair PDF. The engine does not read the file's index, because the index is usually the broken part. It scans the whole file sequentially looking for object headers, steps over stream bodies wholesale so that compressed image data is never mistaken for structure, and collects everything it finds.
The result screen lists every finding: junk in front of the header, streams whose declared length was wrong, compressed object containers unpacked, a page tree rebuilt, a missing catalog reconstructed. Each line names what was done to your file, and there is no generic success message.
The repaired file is verified by re-parsing it before you are handed it, and the result screen tells you whether that succeeded and how many pages came through. Open it and look at the pages - recovery is about structure, and only you can tell whether the content that survived is the content you needed.
A PDF is two things stacked on each other: a pile of numbered objects, which hold the pages, the fonts, the images and the text, and an index at the end of the file that says which byte each object starts at. That index has a name: the cross-reference table. Every reader jumps straight to it and trusts every number in it. Almost every "corrupted PDF" is a file where the objects are perfectly intact and the cross-reference table is wrong.
That is very good news, and it is why this tool works as often as it does.
| Symptom | What actually happened | Recoverable |
|---|---|---|
| "There was an error opening this document. The file is damaged and could not be repaired." | The cross-reference table points at the wrong offsets, or the pointer to it is wrong. The pages are untouched. | Almost always, completely. |
| The file opens but shows blank pages, or fails halfway through | A stream declares a length that does not match its data, so the reader consumes the wrong bytes and everything after it derails. | Usually, completely. |
| The reader says it is not a PDF at all | Something is in front of the header - an HTML error page a download captured, a mail gateway banner, a proxy notice - which shifts every offset in the file. | Almost always, completely. |
| It opens in one reader and not in another | A structurally invalid file that a forgiving reader silently works around and a strict one refuses. | Usually. The rebuild produces something both accept. |
| The file is much smaller than it should be, or ends mid-sentence | A truncated download or an interrupted save. The missing bytes are genuinely gone. | Partially. Whatever arrived is recovered; what never arrived cannot be. |
| Every page is noise or solid grey blocks | The bytes were altered in transit or on a failing disk. The compressed data no longer decompresses to anything. | No. Nothing can invent the original data back. |
The message "could not be repaired" from Acrobat does not mean it cannot be repaired. It means Acrobat's own recovery pass, which is conservative and fast, did not manage it. A rebuild that ignores the index completely and walks the file often succeeds where that gives up.
Still common, decades after it should have died. An FTP client, a mail gateway or an old integration transfers a PDF in text mode and helpfully converts every line ending from one convention to another. A PDF is binary. Every one of those conversions shifts every byte after it, so the file arrives with a perfectly valid index pointing at the wrong places, and inside the compressed streams the data is now damaged too. The structural half of that is repairable; the streams that were altered are not.
This is exactly why every PDF written by this suite starts with a line of high-bit binary characters after the header. It is a marker that tells software the file is not text, and it is the reason those files survive gateways that mangle other people's.
The whole approach rests on one decision: do not trust anything the file says about itself. Not the index. Not the pointer to the index, not the declared length of any stream, not the position of the header. Every one of those is a claim the file makes, and in a damaged document at least one of those claims is false, which is exactly why a reader that believes all of them hands you an error message.
The catalog is the object that says "this is a document and here is its page tree". Lose it and every reader gives up on the whole file. The pages are still there, every one of them. The engine collects the surviving page objects, hangs a fresh tree over them in the order they were written, re-parents each one and writes a new catalog.
None of that is guesswork: the pages handed back are the original objects, untouched. What is genuinely lost is whatever else hung off the catalog - bookmarks, the form definition, embedded attachments, the document outline - because the object that named them is the object that went missing. The result screen tells you that on the spot, instead of leaving you to discover it a week later.
Rule these three out first. Repairing them achieves nothing, and in each case the actual fix is somewhere else entirely.
Always try to get a fresh copy before repairing. Check the sent folder, the shared drive, the version history, the person who sent it. A repair is a genuinely good answer when the original is gone, and a poor one when a complete copy is thirty seconds away.
The honest framing, because this is a category full of tools that promise everything and quietly return a two page document from a two hundred page original.
If the bytes of an object were deleted or overwritten, they are gone. No software invents them back, and any tool suggesting otherwise is describing something else. What a rebuild recovers is everything still structurally present and readable in the file you have, wrapped in a corrected structure. That covers most damaged PDFs, and it is a genuinely different promise from recovering a document.
| Damage | Typical outcome |
|---|---|
| Broken or missing index | Full recovery. Every page, font, image and annotation. |
| Junk in front of the header | Full recovery. |
| Wrong stream lengths | Full recovery in nearly all cases. |
| Missing catalog | Every page recovered. Bookmarks, forms and attachments lost with the object that named them. |
| Truncated file | Everything that arrived, which is usually the first several pages. The rest never reached your disk. |
| Altered bytes inside streams | Structure fixed, damaged pages still damaged. Undamaged pages come through clean. |
One case deserves its own note, because it is the most disappointing and the most misunderstood. A truncated file can be recovered up to the byte where it stops, and everything after that byte was never written to your disk at any point. Recovering four pages out of forty is the honest answer about a file that only ever contained four. The repair did not fail there. The download did.
If the tool finds nothing usable, it says so and does not hand you a file. A one page document containing nothing, presented as a successful recovery, is worse than a clear failure - it wastes the time you would otherwise spend looking for a real copy.
Read this part if it has happened to you more than once. The causes are boring, repetitive and almost entirely preventable.
That last case is a genuinely good use of this tool and has nothing to do with damage. If a system keeps rejecting your PDFs as invalid, rebuild them here. The output is normalized: one clean index, verified stream lengths, no accumulated update history. That is often enough on its own to satisfy a validator which had been refusing the original file for reasons nobody in the building could identify.
Consider what an upload based recovery service is being handed. A document important enough that you are trying to rescue it, in a state where you have no other copy, sent to a machine you do not control. The moment you care most about a file is a poor moment to give it away.
Here the rebuild runs where the file already is. The byte scan, the object collection, the container unpacking and the file writing all happen in this tab, on your processor. There is no upload endpoint because there is no server side to the operation.
Your original file is never touched. The repair is written as a new download and the file on your disk is left exactly as it was, so a repair that does not help costs you nothing and you can try something else afterwards.
Every tool in this suite carries this section. Here is what this one cannot do.
Repair is almost always a step on the way to something else. Something needed to happen to the document and the document would not open.
| What you were trying to do | The order that works |
|---|---|
| Merge a batch and one file breaks the run | Repair the offending file, then merge again. The other tools refuse an unparseable file on purpose rather than producing a broken output. |
| Extract text from a document that will not open | Repair, then convert to Word or to Markdown. |
| Print an archived file that a reader rejects | Repair. A structurally normalized file is often accepted by software that refused the original for no visible reason. |
| Salvage something readable from a partial download | Repair to recover the pages that arrived, then extract the good ones into a clean document. |
| Feed a rejected PDF into a system that validates strictly | Repair to normalize it, then re-submit. One clean index, verified lengths, no accumulated history. |
And keep the original until you have confirmed the repair. The tool never modifies it, so you lose nothing by trying, and a second attempt with different software is always possible. The rest of the PDF suite is built on the same architecture as this page - nothing uploaded, nothing stored, everything on your own machine.
Drop it into the zone at the top of this page and press Repair PDF. The engine ignores the file's own index and walks the raw bytes looking for objects that are still readable, then writes a new document whose cross-reference table is measured as that file is written. The result screen lists exactly what it found and what it fixed. No account is needed for a first run and nothing is uploaded.
Not necessarily. That message means Acrobat's own recovery pass gave up, not that recovery is impossible. Its pass is conservative and fast. A rebuild that ignores the index completely and scans the whole file for objects frequently succeeds where that fails, because in most damaged PDFs the pages are perfectly intact and only the map to them is wrong.
Almost always the cross-reference table - the index at the end of the file that says which byte each object starts at. The objects themselves, meaning your pages, fonts and images, are usually untouched. Junk in front of the header, a wrong pointer to the index, or a stream that lies about its own length all produce the same symptom and all rebuild cleanly.
You get back everything that arrived, which is usually the first several pages, and nothing that did not. The missing bytes are not damaged, they were never on your disk, so no software can produce them. Before repairing, check whether you can simply download it again - that costs a minute and recovers the whole document.
No. The file is read from your disk by the browser, rebuilt in memory, and written back to your downloads folder. A file you are trying to recover is often the only copy of something that matters, and handing it to a stranger at that moment is a poor instinct. Verify by disconnecting from the internet after this page loads.
Never. The repair is written as a new download and the file on your disk is left exactly as it was. A repair that does not help costs you nothing, and you can try other software afterwards on an unchanged original.
No, and the tool tells you so rather than mangling the file. A password prompt means the document is encrypted, not damaged - nothing is broken. Use Unlock PDF with the password you have, and repair afterwards if it still will not open.
Because compressed object containers are unpacked so that every object is directly addressable, which is the trade for an index that is provably correct. Every byte offset in the output was measured as it was written rather than copied from something that was already wrong. The increase is typically small and the file is a normal PDF in every other respect.
Yes. Every surviving page object is collected, a fresh page tree is hung over them, each page is re-parented and a new catalog is written. The pages are the original objects, untouched. Bookmarks, form definitions and embedded attachments are lost, because the object that named them is the object that was missing, and the result screen says so explicitly.
No, and no tool can. That means the bytes inside the compressed streams were altered - by a transfer in text mode, a failing disk or memory corruption - so they no longer decompress to anything. The structure is repairable and the data is not. Look for another copy.
Yes, and it is a genuinely useful thing to do. If a system keeps rejecting your PDFs as invalid for reasons nobody can identify, rebuilding here produces a normalized file: one clean index, verified stream lengths and no accumulated update history. That is often enough to satisfy a validator which refused the original.
Because they search the whole file globally for anything that looks like an object, and compressed image data is full of byte patterns that look exactly like one. This engine scans sequentially instead. When it meets an object holding a stream it jumps the entire stream body in one move, so the contents of a photograph are never read as structure, and the output contains the objects the document really had.
It says so and does not give you a file. A one page document containing nothing, presented as a successful recovery, is worse than a clear failure - it wastes the time you would otherwise spend looking for a real copy. If there is no header anywhere in the file, it also tells you the file is not a PDF at all.
Not for a first run. Anonymous visitors get one operation per 12 hours counted by network address, a free account gets two, and CartHacker Premium removes the counter. One repair is one operation however many pages come out of it. The processing is identical and local at every tier - the damaged file is never uploaded regardless of what you have paid.
All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.
Find the apps that slow your store down, by name and in milliseconds, then answer shoppers' doubts with trust badges under Add to cart. Both are free, with no card and no access to your store admin.
Paste any page and get its three Core Web Vitals, the apps costing time, like Klaviyo or Judge.me, and the Shopify or WooCommerce fix.
Show the promises that settle doubts, from free shipping to a money-back guarantee, right under the Add to cart button. One line in your theme.
Change the link after printing and count the scans. 5 tracked codes on a free account, static codes unlimited.
Anonymous visitors get one operation per 12 hours, per network address. That is not a sales tactic, it is the only lever we have: this tool runs on your processor, not ours, so the run itself earns us nothing. An account tells us who you are, and the ceiling goes up the moment you have one. Your allowance resets in 12 h.
No credit card, no trial period, no sales call. Join with Google, GitHub, Facebook or email.
Free accounts get two operations per 12 hours, and yours reset in 12 h. Waiting costs you nothing and is a completely reasonable choice. If PDF work is a weekly job rather than a one-off, the counter is the wrong tool for you and Premium takes it off the page.
Cancel anytime. Everything you have already produced stays yours either way.