No-upload PDF workflows

This is the job that breaks the "just use a cloud tool" advice. A solo attorney reviewing a client contract, an accountant handling W-2s and 1099s, a healthcare admin under HIPAA, a real-estate agent moving disclosures full of buyer PII — none of them can defensibly upload the document. Cloud PDF services routinely retain uploaded files (Smallpdf lists a 14-day window; others describe vague "automated cleanup" with no hard SLA), and attorney-client privilege, GDPR, and HIPAA did not consent to that retention policy.

Two details matter for real redaction. First, redaction has to actually remove the underlying text, not just paint a black rectangle over it — a box you can select-and-copy behind is a leak, not a redaction. Second, the invisible layer matters: author names, software fingerprints, edit timestamps, and embedded-image EXIF should be stripped before the file goes out, because "professional documents should carry only what you intend."

The fix isn't a privacy argument, it's an architecture choice: process the file on the machine that already holds it. Then there's no trust decision before each operation and no server to audit. You can redact, merge, watermark, and strip metadata offline, keep the original untouched, and confirm the output before it ever touches a network. For a signed PDF with identity, salary, or business details, that local-by-default posture is the whole point.

The concrete versions are everywhere: a 22MB PDF that has to be under 10MB to email, a 300KB PDF a portal insists must be under 150KB, a 50MB scanned contract an online compressor won't even accept because uploads cap at 25MB. And the classic failure — you drag it into a web compressor, get 8MB back, open it, and the text looks like it was printed on a wet napkin. You traded a size problem for a legibility problem.

The reason this hurts is that the portal's size limit is arbitrary and your document is not. The number exists for the receiver's convenience; your file is large because it's a bank statement, an ID, or a scanned medical record — the exact category you shouldn't upload to satisfy a form's cap. So the real task is: hit a target size while keeping the file readable, with a tradeoff you control, and without the document leaving your machine.

What people actually want is a dial, not a single mystery "Compress" button. Predictable tiers help: light compression preserves text and image detail (20-40% smaller, good for print), medium keeps text sharp while softening images (40-60%, fine for email), strong downsamples images to screen resolution but keeps text readable (~60-80%, for archives and internal sharing). Because it's local, there's no upload cap, so a 100MB file compresses in seconds off disk instead of minutes over your connection — and if the first level is too blurry or still too big, you re-run it in seconds.

It sounds trivial until you do it: you've got a handful of images — handwritten notes, a receipt, a signed form, a chapter snapped on your phone — and you need them as one PDF, in the correct order. It comes up constantly for students photographing whiteboards, someone scanning receipts for an expense report, or a signed contract captured page by page.

The usual path turns a five-second idea into a fifteen-minute chore, because the friction is spread across too many tools:

• The multi-tool shuffle — crop in one app, rotate in another, convert in a third, merge in a fourth, babysitting files between each.
• Page-order chaos — phone photos sort by filename or capture time, almost never the order you want, so half the job is dragging thumbnails into sequence.
• Orientation roulette — a few shots come in sideways and you don't notice until the PDF is built and you have to start over.
• The upload tax — the quick web converters want you to upload the images. For class notes, fine; for a signed form, an ID, or a receipt with your details, you've just handed personal documents to a site you'll never think about again.

What "good" looks like is one operation: drop in all the images at once (JPG, PNG, HEIC straight off a phone), order and rotate them visually before export, and get one PDF where each image is a properly sized page — not a tiny photo floating on a giant white sheet — with nothing leaving your computer.

Anyone who's tried it knows the specific frustration: there's a perfectly good table in a PDF — a bank statement, price list, exported report, research dataset — and you just want those numbers in a spreadsheet. So you select, copy, paste into Excel, and get a single column of jammed-together text, or numbers smeared across the wrong cells, or rows merged into each other. The structure is gone and you're retyping by hand.

This is fundamental to how PDFs work. A PDF doesn't store "a table" — it stores text positioned at coordinates on a page. The grid you see is visual; underneath there are often no real rows, columns, or cells, just characters placed to look aligned. So there's nothing structured to copy, and the reader guesses reading order and usually guesses wrong on multi-column layouts or right-aligned numbers. Real extraction means reconstructing the grid from those positions — inferring where the column boundaries are and which text belongs in which cell.

The two common escape routes both disappoint: dedicated "PDF to Excel" services often work but charge a monthly subscription for something you need a few times a month, and the free no-signup converters make you upload the PDF — a genuine problem for a bank statement, invoice, or payroll export. What people want is boring and reasonable: structure-aware extraction that keeps right-aligned numbers in their own cells, output to Excel or CSV you can immediately sort and sum, no recurring fee, and the financial document never leaving the machine.

OCR is easy to demo on a clean single-page scan and much harder on the documents people actually have. The threads are specific: "latest OCR useless on large documents," someone with 16-17 already-compressed 250MB PDFs who can't find a workable path (PDFElement is slow, Mistral OCR is confusing, Gemini caps at 100MB, free sites can't shrink the files enough), and a DataHoarder trying to make digitized bound books efficiently searchable. The common failure isn't that OCR never works — it's that it works just well enough on small samples to earn trust, then collapses when the real archive arrives.

The fix is to treat OCR as a pipeline, not a button. First inspect the file: page count, size, whether pages are scans or already text-backed, image quality, orientation. Then pick the right operation — extract existing text, deskew before recognition, split a huge document into manageable chunks, or produce a searchable PDF that preserves the original visual layout. The useful output isn't just a new file; it's confidence that search will work later. You should be able to test it immediately: find a known phrase, copy text off a page, confirm the file still opens in ordinary readers, and check that the size didn't explode.

Doing this locally is what makes the large and sensitive cases workable at all — no upload cap to fail against before OCR even starts, and no privacy review before you run it on a scanned contract or a public-sector archive that legally shouldn't leave the workstation.

File conversion gets hardest exactly when the file is oddest. Real examples from the threads: converting a 2GB-plus PDF into PNGs after online sites and Microsoft Store apps crashed or errored, opening a 70MB generated PDF on Linux, converting 1,400 obscure .FIF images for archival work, and a museum-scale batch of formats that no single mainstream app really owns. When the tool is remote, every attempt costs an upload, a wait, and a vague failure — and if a cloud converter dies after a long upload, you're left with an error and a bad feeling about where the file went.

Local conversion changes the center of gravity: instead of asking whether a third-party service can temporarily handle the file, you ask what can be done directly on the machine where it already lives. If a conversion fails, you still have the source, the intermediate result, and a clear next step. Format breadth is only useful with control, so a good workflow lets you make a conservative choice — PNG or TIFF for image preservation, JPEG or WebP for sharing, PDF as a container when pages must stay searchable — and keep the original beside the output. The key is reversibility: crop, compress, deskew, convert, and extract should produce visible outputs you can compare against the source, so weird files get handled inside a predictable local routine instead of a one-shot upload-and-hope cycle.

A PDF form looks like paperwork until the moment it blocks a deadline. Then it becomes a file problem: the fields don't line up, the portal rejects the size, the signature tool wants an account, and the only search results are upload sites that ask for the document before they explain what they do with it. The files involved are rarely neutral — tax PDFs, onboarding forms, medical packets, school paperwork, vendor forms, signed declarations — all carrying identity, salary, address, or business details that shouldn't move through a random converter just because the form is annoying.

The form is also rarely the whole job. Filling a company tax PDF, you may also need to merge supporting pages, compress the final packet under a portal limit, rotate a scanned attachment, or OCR an old form so it's searchable. Single-purpose web tools make that brittle: one page fills fields, another merges, another compresses, and each handoff asks you to upload again and hope the previous step didn't flatten the wrong layer or break selectable text.

Good local form filling also respects reversibility — keep the original, save a filled copy, test the compressed output, and only then submit the version that meets the requirement. And when you're done, flattening the form locks your entries so they can't be edited or accidentally changed by the recipient. The absence of an account isn't a missing feature here; for sensitive documents it's part of the value: the file stays local, you stay in charge, and the tool gets out of the way when the job is done.

It's the math you've already done in your head. Adobe Acrobat Pro is $20/month — $240 this year, $720 across three — for a PDF editor you use maybe three times a week. Smallpdf Pro is $12/month ($144/year), iLovePDF $7/month ($84/year), and none of them let you keep the software if you stop paying. The threads add sharper versions: someone whose end-of-life Acrobat still works but who refuses to pay $180/year just for light fillable-PDF work, and freelancers stacking $9 Smallpdf + $9 iLovePDF + $14 PDF Expert + $7 for a watermarking tool into ~$40/month of recurring spend. That's subscription fatigue, and it's what sends people searching for an alternative.

There's a structural reason these tools are subscriptions: they run the heavy operations — rendering, compression, OCR — on cloud servers, so they need recurring revenue to cover ongoing compute. A tool that runs everything on your own CPU has no per-use server cost to recoup, which is exactly why a one-time purchase is even possible. The tradeoff people are choosing is straightforward: for occasional-but-real PDF work, a single purchase you keep forever beats renting a cloud service that keeps deducting and disappears the day you cancel. The bonus is that the same local suite usually covers image, video, audio, and file chores too, so you also stop paying for a pile of single-purpose tools.

Watch a freelancer prep one client deliverable and you'll see the same six-step dance: open the source PDF, compress it because it's 38MB, switch to one tool to redact the bank-account line, switch to another to watermark a low-opacity DRAFT stamp, run a script to merge two attachments, sign, rename, email. Do that fifteen times a week across invoices, contracts, scanned receipts, and KYC IDs and the per-deliverable workflow becomes its own job. On the review side, the pain is the mirror image — a mortgage applicant with 17 separate PDFs, frustrated just opening and closing documents to check them.

What finally collapses this isn't a better single tool, it's making the workflow repeatable. Four categories of step show up in almost every chain: size and format (compress under the client's limit, convert to PDF/A so it renders the same everywhere), privacy and redaction (strip metadata, redact PII), identity and branding (watermark, footer, page numbers), and bundle and delivery (merge attachments, password-protect, rename to a consistent pattern like 2026-05-13_ACME_Invoice-0142.pdf). Cloud tools fail this shape three ways: each step is a separate tab and a separate upload, the source file leaves your machine, and there's no preset memory — you re-pick every setting every time.

The local fix is a saved preset (named for the use case, not the steps) plus a watched folder: drop a file into an inbox directory and the whole chain runs against it automatically, output landing in an outbox, source bytes never transmitted. It's the freelancer's Makefile for deliverables — the workflow you run repeatedly should not be the workflow you re-decide repeatedly.

The recurring advice in file-tool threads is blunt: don't take a converter's "100% private, nothing leaves your browser" banner at face value — check it. And you can. While the tool runs, open your browser's developer tools, switch to the Network tab, then drop your file in. A genuinely local tool shows no large outbound request; a tool that's quietly shipping your file to a server shows a POST carrying your document as the payload, often to an API or storage host you've never heard of. People who care go further — they watch the file size climb on the upload row, or throttle the connection to see whether "processing" secretly depends on a round trip to finish.

This matters because the marketing claim and the network behavior are two different things. Plenty of "free, no-signup" converters really do upload — that's how they render, OCR, or compress on a server — and their privacy copy is describing an intention, not an architecture. For a bank statement, an ID scan, a signed contract, or an HR export, "we delete it later" is a retention policy you're being asked to trust, not a promise that the bytes never left your control in the first place.

The cleaner fix is to remove the trust decision entirely. If there's no server in the loop, there's nothing to verify before each job and nothing to audit afterward. A tool that processes files locally can be checked once, definitively, instead of inspected every single time: cut the machine off the internet, run the job, and see whether it still completes. If it works with the network off, the file physically cannot have been uploaded.

For the general version of this test applied to any converter or "browser-based" tool (not just PDF sites), see how to verify a tool is really local.

The ask shows up constantly in its plainest form: someone wants a fast desktop app that combines PDFs, shows a thumbnail of every page, and lets them drag those pages into the order they want before exporting — nothing more. Acrobat does it but feels bloated for a job this small, and the free web mergers are speed-dependent on your connection and want the files uploaded first. The friction, not the capability, is the problem: a five-second task shouldn't require a heavyweight install or handing a contract to a random site.

Two details separate a real merge tool from a toy. First, previews: filename order is almost never page order, so you need to see thumbnails and drag them, not guess from scan_047.pdf and scan_048.pdf. Second, page-level control after combining — a merged packet usually needs a stray page deleted, a sideways scan rotated, or two sections swapped, and doing that in the same place beats re-exporting through three more tools. People comparing Mac PDF alternatives list exactly this cluster: merge, page management, rotate, delete, reorder — the boring plumbing of assembling one clean document out of several.

The reason to keep it local is the same as every other sensitive-file job. A merged packet is often an application bundle, a signed agreement, or a stack of scanned IDs, and the moment you upload it just to reorder pages you've handed the whole thing to a stranger's server to save yourself a drag-and-drop. Local page assembly means the visual reordering happens on your machine, the source files stay untouched, and the combined PDF is written straight to disk.

This happens because a lot of editors take the lazy path on save: they rasterize the page — turning crisp vector text into a flat image — or they append an entire new revision of the document on every edit. So a two-word correction can double the file size and leave the text looking soft, because it's now a picture of text rather than text. On a form or a contract that also breaks selecting, searching, and copying later.

Two things make edits behave. First, the edit should touch only what you changed: adding a text box, an annotation, or a redaction over one clause should leave the rest of the page as the real characters and vectors it already was, not re-flatten the whole thing. Second, do a proper compress or linearize pass at the very end — that flattens the accumulated revision history into one clean copy and reclaims the size that incremental saves quietly piled up.

There's a privacy wrinkle in the same mechanism. Because incremental saves append rather than overwrite, earlier revisions — including text you thought you deleted or 'redacted' — can still be sitting inside the file. A real redaction removes the underlying content, and a final rewrite pass is what actually drops the leftover history before the file leaves your machine.

This is one of the most demoralizing PDF jobs there is: the work is already done, and a layout change threatens to make you redo all of it. Set expectations honestly first — there is no universal one-click "migrate my answers" button, and any tool that promises one is guessing. A redesigned template usually renames or reorders its fields, so nothing can reliably know that "Applicant Name" on the old form maps to "Full legal name" on the new one. That mapping is a judgment only you can make, once.

What you can avoid is the retyping. The efficient path has three parts. First, get the values you already entered out of the completed PDFs — pull the text so every answer sits in one place instead of buried across dozens of files. Second, fill the new template from those values, field by field once, rather than transcribing from a printout. Third, if the finished forms are going to anyone, flatten them so the fields become part of the page and can't be edited or accidentally re-flowed downstream.

The other reason to keep this local: filled forms are usually full of personal data — names, addresses, SSNs, account numbers, medical or financial details. Feeding dozens of them through an online form tool hands all of that to a server you don't control, for a job that never needed to leave your desk. A local workbench does the extraction and the filling on your own machine, so the data in those forms stays where it started.

The reason is baked into what a PDF is. A PDF does not store editable paragraphs the way a Word document does. It stores drawing instructions: place this glyph at these coordinates, in this font, at this size. There is no "sentence" object to click into, only hundreds of individually positioned characters that happen to line up into what your eye reads as a line of text. So when a tool claims it "edits text," it is usually doing one of two very different things, and the difference is the whole story.

The honest, easy path is an overlay: the tool draws a new text box on top of the page. That is fine for adding a signature line, filling a blank, or stamping a note, but it cannot reflow an existing paragraph. Try to change a word that is already on the page and you end up with a white rectangle patched over the old text and new text floating above it — which is exactly why so many free editors feel like they are faking it. The hard path, true content-stream editing, means parsing those positioned glyphs back into editable runs, re-shaping the line, and re-embedding the font. It is genuinely difficult, which is why most tools quietly avoid it and the honest ones tell you up front that they only overlay.

Knowing which one you are using saves the frustration. If the job is adding text — a form field, a note, a signature — an overlay is the correct tool and works everywhere. If the job is rewriting existing copy, like fixing a typo in a body paragraph or changing a figure in a contract, the more reliable route is to convert the page to an editable format, make the change in a real word processor, and export back to PDF, instead of fighting an overlay tool into pretending it can retype the original.

This is a deliberate trap, not bad luck. A large class of "free" online PDF editors are free to use and expensive to finish. You can open the file, move things around, fill the fields, feel productive — and the payment wall appears at the one moment you cannot walk away from: export. Sometimes it is a subscription prompt at download, sometimes the file comes out stamped with a watermark you can only remove by paying, sometimes the layout quietly shifts on the way out so the clean version is the paid version. The common thread is sequencing. They collect your effort first, because sunk effort is the leverage. Once you have spent twenty minutes fixing a resume, paying to actually get it out feels less painful than starting over somewhere else — which is exactly the calculation the design is built around.

There is a second cost that is easy to miss. To edit and re-export your file, that service had to receive it, so your resume, contract, or tax form was already sitting on someone's server before you knew there was a bill. The privacy exposure happened during the part that looked free.

The way out is to see that the export gate only exists because the tool controls the output. A tool that writes the finished file straight to your own disk has nothing to hold hostage: there is no download to meter, no watermark to sell you the removal of, and no upload that put the document on a stranger's machine to begin with. The practical rule for any "free" editor is to find out what happens at export before you invest the editing time, not after — and to be most suspicious precisely when the editing itself feels generous.

Markdown quietly became the working format for a lot of real writing — notes, docs, AI output, README-grade reports — and the last step is always the same: someone wants a PDF. The two standard answers are both bad at this scale. A LaTeX/pandoc toolchain produces beautiful output but is a gigabyte of install and a config rabbit hole for what should be a ten-second export. Online converters are fast but you're uploading the document — fine for a changelog, not fine for the client report or the contract draft — and the styling is a lottery you can't inspect.

The structure of the job matters: Markdown is the source of truth; the PDF is a disposable export artifact. Any workflow that makes you edit the PDF, or that styles the conversion somewhere you can't reproduce, breaks that. What you want is a boring, repeatable, local pipeline: Markdown to styled HTML (this is a lossless, well-defined transformation), then HTML to PDF — which every browser already does natively and consistently via print-to-PDF, with page size, margins, and headers under your control.

That two-step also explains why "fast standalone Markdown-to-PDF" keeps being asked for as if it were exotic: the pieces are commodity; it's the no-install, no-upload, no-config combination people actually want. If your writing lives in a heavier format already — Word, Typst, LaTeX — export from there instead; the mistake is round-tripping Markdown through Word just to reach PDF, which mangles code blocks and spacing for no benefit.

The Google Docs trick fails because it's not a converter — it's an importer doing its best. A PDF is a layout format: it records where every glyph sits on the page, not what the document structure is. Word is the opposite — structure first, layout derived. Converting between them means reconstructing paragraphs, columns, tables, and fonts from coordinates, and Docs' importer gives up early on exactly the documents people most need converted: resumes, which are built from multi-column templates, text boxes, icons, and tight spacing.

First, diagnose which of two different problems you have. If you can select and copy text in the PDF, it's born-digital and a real converter can rebuild the structure — expect to fix some spacing, but the content arrives intact. If you can't select the text, your "PDF" is a photograph of a document, and no import will ever work until OCR turns the image back into text; that's a different tool, not a harder setting.

Two more practical outs before you convert at all: if the PDF was ever exported from Word, the original .docx is the conversion — chase that first. And if the goal is feeding an application portal, check whether it actually requires Word or just accepted it historically; many take PDF and parse it better.

What you shouldn't do is upload a resume — a document containing your name, address, phone, and employment history — to whichever free converter ranks first. This is one of the clearest cases where the file should never leave your machine.

This is one of the most stressful file jobs there is, because it usually shows up against a deadline: a court e-filing portal, a grant submission, a job-application system, all of which reject anything over a fixed size and none of which care that your document is legitimately 1,500 pages. The desktop suites that should handle it are exactly the ones that stall or crash on a file that large, and the free web splitters cap the upload well below the size you're trying to work with — or would have you upload a confidential document to a stranger's server to shrink it.

The key realization is that "split into equal page counts" and "split under a size cap" are not the same operation. A hundred pages of scanned images can dwarf a thousand pages of plain text, so a naive page split can still leave you with one chunk over the limit. So do it in two moves. First split the document into ranges — by a page count you pick, or into specific ranges that match logical sections. Then compress each part and check its actual size on disk; if a chunk is still over, split that one further or compress it harder. It's a little iterative, but it's deterministic and you can watch the byte count come down.

Because every step runs on your own machine, the 1,500-page file never leaves your drive, there's no upload ceiling to fight, and the original stays untouched while you produce the portal-ready pieces alongside it.

Printing a folder is not the same job as printing a document, and almost every print dialog treats it as one. Select a hundred files, choose 2-up, and the spooler concatenates the stream: a document with an odd page count leaves half a sheet free, and the next document starts there. You find out at the printer, an hour in.

The fix is to make each file its own print job with an even page count.

• Pad every odd-length document. Append one blank page to any PDF with an odd page count and 2-up boundaries stop crossing. This is the whole trick, and it works with any printer.
• Print per file, not per selection. One job per document — slower to queue, but each one starts on a fresh sheet by construction.
• Fix the order before you start. Folder order, name order, and print order are three different things. Number the files explicitly if sequence matters.
• Preview the plan, not the pages. A list of files, page counts, which will get a padding page, and total sheets tells you in ten seconds whether the run is right. Discovering a mistake on sheet 200 costs paper and an afternoon.
• Keep a manifest. For a run this size you want a record of what was sent, in what order, so a jam at file 60 doesn't mean restarting from the top.

Do the padding and ordering as file operations first; the print dialog then has nothing left to get wrong.

You're asking for two different things and they trade against each other. Be explicit about which one you want per output, because no tool can maximise both.

Editable reconstruction rebuilds the document as text, paragraphs, and tables. You can type in it, and the layout is a best-effort guess. Multi-column forms are the hardest case: the converter has to infer that two visually adjacent boxes are separate fields rather than one flowing line, and it often gets that wrong.

Visual fidelity keeps the page exactly as drawn — a page image, or a PDF you annotate on top of. Nothing moves, nothing reflows, and nothing is editable as text.

How to choose:

• Filling it in? Don't convert at all. If the PDF has real form fields, fill them in place. Converting a fillable form to Word usually destroys the fields — the one thing that made it useful.
• Editing the wording? Accept the reconstruction and budget cleanup time. Column-heavy layouts will need manual fixing; that's the price of editability.
• Sending it, printing it, or dropping it into a slide? Use page images. PNG per page preserves placement exactly.
• Check the first page before converting all forty. Conversion quality is a property of the file, and one page tells you what you're dealing with.
• Keep the original. Every conversion is lossy in one direction or the other; the source PDF is the thing you can always go back to.

Interleaving is a two-line operation on the file and a paywall on most web tools, because it's exactly the kind of job people will pay to finish once they've already uploaded a document.

The operation itself is simple: take page 1 of A, page 1 of B, page 2 of A, page 2 of B, and so on. What makes it go wrong in practice is everything around it.

• Check the page counts first. Two documents that should match rarely do — a cover page, a blank, a different edition. If A has 212 pages and B has 210, everything after the mismatch is misaligned, and you won't notice until page 90.
• Decide what happens at the mismatch. Pad the shorter one, or stop and fix the source. Silent truncation is the behaviour that wastes a print run.
• Confirm the offset with a spot check. Look at the interleaved result at pages 1–4 and somewhere in the middle. Two checks catch nearly every alignment error.
• Think about the fold if you're printing double-sided. Interleaved output prints as facing pairs only if the first page lands on the right side; an extra blank at the front usually fixes it.
• Mind the page sizes. Two scans at different dimensions will interleave fine and print inconsistently. Normalising size beforehand saves the reprint.

And since both documents are yours, there's no reason for either to leave the machine to do it.

Because cropping in most PDF tools doesn't remove anything. It sets a crop box — a viewing rectangle — while the underlying page keeps its original dimensions and its content stays there, just hidden. Viewers respect the crop box, so it looks right on screen. Print pipelines and imposition tools frequently use the media box instead, so they lay out the original oversized page and your content ends up small and off to one side.

That's why the same file looks correct in a viewer and wrong on paper.

What to do:

• Distinguish hiding from removing. If you need the crop to survive printing, the page geometry has to actually change — content outside the visible area removed and the page boxes rewritten to the new size.
• Normalise all the boxes together. Media, crop, trim, bleed, and art boxes should agree after the operation. A mismatched set is what most booklet tools trip over.
• Split before you crop for two-up scans. Cut each landscape sheet into two portrait pages first, then normalise. Doing it in the other order is where most of the pain comes from.
• Check one page's dimensions after processing. The page size readout should be the size you wanted. If it still reads as the original, nothing was removed.
• Verify with a two-page test print before committing 400 pages and a binding.

Once the geometry is genuinely correct, the imposition step becomes boring — which is what you want at this scale.

A screenshot captures the figure at your screen's resolution, which is roughly a quarter of what you need for a projector and nowhere near enough for print. But the figure inside the PDF is usually stored at its original resolution — you just have to take it out rather than photograph it.

Two cases, and telling them apart saves you time:

• Embedded raster images (photographs, micrographs, screenshots in the paper). These extract at full original resolution. This is the good case, and it's most figures in most papers.
• Vector figures (plots, diagrams, anything drawn). There is no image object to extract — the figure is drawing instructions. Extraction returns nothing, or fragments. Instead, render the page at high DPI and crop, or export the page region as vector if your target supports it.

Practical notes:

• Extract, then check the pixel dimensions. If a figure comes out at 400×300, it was placed at low resolution in the source and no tool can recover more.
• Pick the format for the destination. PNG for line art and screenshots; JPEG for photographs when size matters; TIFF when a journal asks for it.
• Expect extras. Extraction pulls every image object, including logos and background elements. Batch naming by page makes sorting quick.
• Watch for tiling. Some figures are stored as several strips that need reassembling — if you get three thin slices, that's what happened.
• Keep attribution with the file. Extracted figures lose their caption instantly; a filename with the paper and figure number saves you later.

Browser and Drive previews fail on image-heavy PDFs for reasons that have nothing to do with the number on the file size — they choke on how the images are stored, not just how big the file is. A 15 MB PDF can fail to preview while a well-built 8 MB one loads instantly, because previewers give up on files that force them to hold too much in memory at once.

The fix is to right-size the images and structure the file, not just crush the whole thing:

• Match image resolution to display, not to the source. A page rendered at 4000px when it displays at 1200 is three-quarters wasted weight the previewer still has to decode. Down-sampling images to a sane DPI recovers most of the size without the visible mush you get from compressing everything blindly.
• Compress the images, not the text. Blanket compression is what makes the 5 MB version look bad. Re-encoding the embedded images while leaving vector and text layers alone keeps pages sharp at a fraction of the weight.
• Watch colour space and transparency. Large RGB images and heavy transparency are common preview killers; flattening them is often what tips a file from "won't load" to "loads instantly."

Do it locally and you can iterate — export, check the preview, adjust — without uploading a contest entry or a client draft to a service just to find out whether it renders.

Most of PDF-to-Markdown is a layout problem, not a reasoning problem — and that distinction is why paying an LLM per page is usually overkill. Headings, columns, reading order, and tables are geometry: where text sits on the page, how blocks group, which runs are larger or bolder. Deterministic local parsing handles that class of document well, without sending your file anywhere or metering tokens.

The practical split is knowing where deterministic parsing ends:

• Extract text with its structure first. A local parser that reads the PDF's own text layer gets you headings, paragraphs, and reading order directly — no model guessing required. For any PDF that already contains real text, this is the whole job.
• Tables are geometry too. Column and row boundaries come from coordinates, not comprehension. Local extraction preserves the cell grid a language model would only approximate.
• Reserve vision models for genuinely hard scans. A skewed photograph of a multi-column page in a mixed script is where a model earns its cost. Everything before that boundary is deterministic and free — and offline.

Start local and deterministic, keep the file on your machine, and escalate to a model only for the pages that actually need one. Paying for layout analysis on documents that already carry their own text layer is paying for a reasoning tool to do arithmetic.

Two separate problems wearing one error message. The document is fine; the sync client's belief about the document is not. Once the cloud layer has marked a file as being in a failed upload state, features that route through it can refuse — and every "Save a Copy" you make to escape leaves you with a folder of near-identical files and no idea which one is current. That second problem is the one that loses work.

Fix ownership first. Get one authoritative copy out of the synced folder entirely — save to the Desktop or any non-synced path, then close the original. Now the file exists somewhere the sync client holds no opinion, and you can work without negotiating with it.

Then export locally. Two routes, neither needing a cloud round-trip: Save As with PDF as the file type, or print to PDF, which bypasses the export path completely and is the dependable fallback when the app's own exporter is the thing misbehaving. Print-to-PDF costs you tagged structure and live links — it produces a visual copy — so prefer Save As when it works and keep print as the backstop.

Then verify before you send or replace anything. Both a stuck exporter and print-to-PDF are entirely capable of producing a file that opens and is wrong. Check that the page count matches your expectation, pull the text out to confirm it's real text rather than an image of text, and glance at whether anything spilled off a page. For a workbook, check the print range too — the most common silent failure is exporting one sheet, or forty pages of empty columns.

Then, last, deal with the cause — clear the sync client's cached state, sign out and back in, check whether the file is locked by another session. Do it after the PDF is in your hand, not before. The general rule this incident is teaching: never let a document you need exist only inside a sync client that is currently failing.

Do not start by stripping metadata or printing the PDF to another PDF. A print rejection about ICC profiles is a production-spec problem: the portal wants a particular color space and PDF standard, and a generic rewrite can make the warning disappear while quietly changing color, flattening transparency badly, substituting fonts, or moving the page boxes.

Keep the delivered cover as the untouched original. Then use a prepress-capable PDF editor or go back to the cover designer with the portal's exact error. The correction should be made against the printer's current file-creation guide: inspect the objects that are still RGB or profile-tagged, verify fonts and page geometry, convert color with the intended print profile, and export to the specific PDF/X target the portal requested. PDF/A is an archival standard and is not a substitute for PDF/X.

Before uploading the corrected copy, compare it with the original page by page. Check the trim size and bleed, look closely at gradients and dark colors, confirm text did not reflow or rasterize, and verify that every font still renders. If possible, have the designer or printer confirm the output rather than relying on a browser converter whose transformation you cannot inspect.

The safe sequence is diagnose, correct from the source when possible, export to the requested print standard, then visually and structurally compare. The goal is not merely to silence the upload warning; it is to preserve the cover while satisfying the press workflow.

Two operations get conflated here and shouldn't be. Splitting a spread is a geometry change — one page becomes two. Cropping alternating margins is a per-parity rule, because the outer edge swaps sides on every turn, so odd and even pages need mirrored rectangles. Most PDF editors offer one rectangle for the whole document, which is exactly why every route you've found makes you produce two documents and re-merge them.

The crop-twice-then-merge dance does work, and it's worth naming why it's fragile: two crops of the source give you two documents in the wrong interleaving — all the left pages, then all the right pages — so merging them produces 1, 3, 5… followed by 2, 4, 6…. Getting back to reading order needs an interleave, not a merge, which is the step most people discover after printing.

A local route that avoids the tool-hopping:

• Rasterise, crop by parity, reassemble. Export the pages to images, apply one crop preset to the odd files and a mirrored one to the even files in a single batch, then rebuild the PDF. You lose the text layer — which only matters if the scan had already been OCR'd, and if it had, run OCR again at the end.
• Handle the title page as an exception up front. Extract it, process the rest, put it back. It's almost always the page that breaks a batch rule.
• Check three pages before committing to four hundred. The first spread, one from the middle, and the last. The failure that costs you is a crop clipping page numbers or inner text on one parity only, and it stays invisible until you're reading on the tablet.
• Keep the original. Every step here is destructive to something.

One trap if you're printing a booklet afterwards: a crop that only sets a viewing rectangle won't survive imposition. The split has to genuinely produce new pages.

It can, and the technique is more reliable than it sounds — but there are two failure points worth understanding before you run it across a shelf of books.

The mechanics: OCR the table-of-contents pages, parse the hierarchy from indentation and numbering, then map printed page numbers onto actual PDF page indexes. That last step is the one people forget. A book's printed page 1 is rarely the PDF's page 1 — a cover scan, front matter, and blank versos shift everything by a constant. So the offset has to be detected (jump to one entry, confirm the target page matches) and then applied across the set. Get it wrong and every bookmark is confidently wrong by the same amount, which is worse than having none at all.

Where it breaks:

• Multi-column tables of contents. Reading order across columns is the most common failure — entries interleave and the hierarchy comes out scrambled.
• Scripts and layouts the parser wasn't tuned for. Indentation heuristics get built against whatever documents the author had to test with. If yours are in a different script, expect degraded parsing rather than a clean failure — and check, because it won't announce it.
• Dot leaders and ornamental typography, which OCR happily reads as characters and the parser then folds into the title.

So treat the output as a draft with a review step. Before writing bookmarks into the file, read the parsed list next to the detected offset and spot-check three entries — first, middle, last — and keep the original. A bookmark tree is cheap to regenerate and annoying to un-wrong once it's embedded.

Most extractors detect tables from ruling lines, and the documents you're describing are precisely the ones that don't use them consistently. A financial statement puts a rule under the header and whitespace everywhere else. An academic table spans a header across three sub-columns with nothing drawn between them. Line detection sees either one giant cell or a column boundary that isn't there, and the CSV that comes back is structurally wrong in a way that still looks plausible enough to paste.

The approaches differ in what they reason about:

• Ruling-line detection is fast and correct on fully bordered grids. It has no model of what a header is, so a merged cell is invisible to it.
• Layout and table-structure models infer rows, columns, and spans from the visual arrangement rather than from drawn lines. This is what survives merged cells and nested headers, and it's why the newer generation of tools works where the older ones didn't.
• Text-position clustering sits between the two — better than lines, still weak on spans.

Whichever you use, treat the extraction as a draft. Three checks catch nearly everything:

• Column count per row. Any row disagreeing with the header count is where a merge got flattened.
• Totals. Financial tables usually carry their own checksum. If a column doesn't sum, the extraction moved a number.
• The header itself. A nested header should come out either as multiple rows or flattened with a separator. Silently collapsing to one row is the most common corruption and the one you notice last.

One structural point worth accepting early: a nested header is a two-dimensional label and CSV has no way to express that, so something has to flatten it. Deciding how yourself beats letting a tool choose quietly.

Print-to-PDF re-generates the document through a print driver rather than copying it. Along the way the original fonts get substituted or badly subset, and when the encoding map doesn't survive the trip the glyphs still draw but the underlying characters become nonsense. That's exactly your symptom: it looks wrong on screen, and copying text out gives you garbage. Text-heavy forms with embedded subset fonts are the most fragile case, and print-to-PDF is the least reliable way to duplicate them.

What you actually wanted was "save a copy with the values baked in," and that's a different operation:

• Flatten the form. Flattening turns filled fields into ordinary page content, so values can't be edited or accidentally cleared later, and no print pipeline is involved. This is the right tool for the job you described.
• Or Save As, not Print. If the fields need to stay fillable, saving a copy preserves the original object structure. Print-to-PDF never does.
• Keep the template untouched and generate each client copy from it — which is what you were trying to achieve in the first place.

The merge problem people hit alongside this has the same root. Merging PDFs built from 300-PPI images should be lossless, because a merge copies page objects. Tools that re-render pages during the merge will resample and shift elements instead. The tell is file size: if a merge changes it dramatically, or anything moved, it re-rendered rather than copied. Compare one page before and after — a clean merge leaves pages pixel-identical.

For client forms and health records, both operations belong on your machine. This class of document is the entire reason the upload question matters.

Nothing is broken in the file-corruption sense. In an AcroForm, the field name is the identity of the value. Two widgets sharing a name are not two fields — they are one field drawn in two places, which is a deliberate feature used for things like a signature date that should appear on every page. Whoever built this form duplicated a page or copy-pasted a row of widgets without renaming them, so the mirroring is the format working exactly as specified against a mistake in the document.

That also explains why editors refuse. Most consumer PDF tools expose filling, not the form's structure, and the ones that do let you rename a field often rename the parent — which renames every widget under it and changes nothing about the mirroring.

The repair is a rename at the widget level, and the order matters:

• Read the field tree first. List every field with its full qualified name and its widgets, with page numbers. Duplicates in a form built by copy-paste usually appear in a recognisable pattern, and that pattern tells you which group is the accidental one.
• Rename only the offending widgets, giving each its own unique name. Leave the group you consider canonical untouched, so any external process that references those names still works.
• Preserve the appearance stream and the widget rectangle. This is where naive repairs go wrong — the field ends up functional and visibly different, or invisible until clicked.
• Check calculations and validation. If any field is computed, its formula references field names, and renaming a referenced field silently breaks the calculation. Update the formulas along with the names.
• Fix the tab order while you are in there; duplicated widgets usually disturb it.

Then verify properly, because "it looks right in the editor" is not the test: save, close, reopen in a different viewer, and type distinct values into the previously-linked fields. Reopening matters — appearance streams are regenerated on load, and a broken repair often looks fine until the file is reopened somewhere else.

If the form came from an organisation you have to submit it to, tell them. You have found a defect in their template, and a repaired copy may not be what their processing system expects.