One operation per tool, one order per job
Each tool does one thing well. Most real jobs need three of them. This page sets out eight sequences that solve something concrete, three orders that quietly ruin a document, and why there is no automated runner — a runner would need a job queue, and a job queue would need a server.
A chain, drawn
result, three steps later
Three downloads · three round trips? No. Zero network at all — each step reads the file from your disk.
Eight sequences
Each card names a real situation, the tools in order, and the failure mode the order is designed to avoid.
A stack of printed pages photographed or scanned, needed as one file that can be searched and emailed.
OCR before compressing. Compressing rasterises pages, so doing it first throws away the text layer you just built.
Twelve separate PDFs from a counterparty need to become one paginated document that requires a password.
Protect last. Adding page numbers to an encrypted file means unlocking it first, which is a second copy of the problem.
A .docx containing client names has to go out with those names genuinely removed, not covered.
Convert first so the words are fixed, then redact the PDF. Redacting a document that is still editable means the next edit can reinstate the text.
A 300-page report where one 40-page section has to go to a client, at a size that fits an inbox.
Extract before compressing. Compressing the whole 300 pages to shrink a 40-page extract wastes memory and quality.
A design proof that must be viewable but not copyable, and an open password is not appropriate.
A browser print-to-PDF also works here. Either way this is a cosmetic control, not a security one — the honest limit is stated on both tool pages.
Pages photographed sideways with a dark scanner edge showing, and the file is far too large.
Crop before compressing. Compression decides what to keep based on the current page box, so trimming the edge first saves more.
The other side has returned a marked-up version and you need a record of the changes plus your signature.
Compare first and keep the highlighted copy. A signature applied before a comparison makes the comparison ambiguous about which version was signed.
One chapter of a technical manual needs to become Markdown you can paste into a notes app.
Extract first on a large file: converting 300 pages to Markdown when you need 40 is a slower path to the same text.
Read this before you start
Each of these produces a file that opens, looks plausible, and has lost something you cannot get back without starting again from the original.
Compress, then OCR
Compressing re-encodes pages as images. Recognising text on top of a compressed image works, but the result is a guess about pixels rather than characters. OCR the original, then decide whether you can live with losing the text layer.
OCR first, and only compress if the size genuinely matters.
Redact, then convert to Word
A redacted page is an image, because that is what guarantees the removed characters are gone. Converting that image to Word produces a file with no text and a picture of a page — the opposite of what a Word conversion is for.
Decide which you need. Redaction and re-editability are mutually exclusive.
Sign, then merge
A signature is placed at a position on a page. Merging after signing changes the document the signature refers to, and a signature page inserted in the middle no longer means what it meant when it was applied.
Assemble and paginate first; sign the finished document.
The rule behind the recipes
Almost every ordering mistake comes from doing an irreversible operation before a structural one. Three passes over the file in this order will not go wrong.
What each pass changes
Stated plainly
A runner means queueing jobs, storing intermediate files between steps, and tracking a run across page loads. Each of those is a server-side feature. The moment this page offered a “Run chain” button, the privacy claim would need a caveat, and the caveat would be the whole story.
What you get instead is the thing that makes chaining pleasant without a queue: every step takes a file from your disk and returns one in a couple of seconds, with no upload and no sign-in between them.
When not to chain at all
Long chains usually mean the underlying document is the problem, not the tooling. Re-export from the source, ask the sender for a better scan, or accept that two versions of the file is the honest answer. Chaining three irreversible operations in a row is how people end up with a 40 MB file that contains a photograph of a spreadsheet.
Start with step one
Every tool takes the previous output, so the chain is only ever one click longer than a single operation. No account links the steps together, because there is no account.
no runnerno upload between steps