Every few weeks a PDF lands on my desk that needs something done to it. Shrink it so an email will accept it. Pull a table into a spreadsheet. Merge four scans into one file. For years the reflex was to open a heavy desktop app, or worse, to pay for one just to run a two-minute task. That reflex is out of date. Almost all of it now runs in a browser tab, and some of it runs from a script.
I want to walk through the ones I actually use, and where the line sits between "do it in the browser" and "automate it."
The one check that saves you every time
Before touching any PDF tool, find out what kind of file you have. Select a word on the page. If it highlights, the text is real and any conversion will be clean. If nothing highlights, the page is an image (a scan), and you need OCR to get text out of it.
This sounds trivial, but it explains most "the converter mangled my file" complaints. A native PDF converts faithfully. A scanned one goes through character recognition, which is good but not perfect, so you review the output. Knowing which you have sets your expectations correctly before you start.
Shrinking a PDF for email
Mail providers still cap attachments low: Gmail at 25 MB, Outlook around 20, plenty of corporate servers at 10. A 300-DPI scan blows past all of them.
Compression re-encodes the images inside the file while leaving the text sharp. Medium compression is the sweet spot for email: the file drops several times over and you will not see the difference on screen. Keep maximum quality only when the destination is a professional printer.
Getting tables out of a PDF and into a spreadsheet
This is the one that used to eat my afternoons. Copy-pasting a PDF table into a spreadsheet collapses it into a single column of run-together text, because a PDF stores text at fixed coordinates, not as a real grid. A proper conversion reads the position of every value and rebuilds actual cells, so numbers land under the right headers.
For one-off files, a browser tool is the fastest path. When it becomes routine, say a nightly batch of statements, this is where automation earns its keep.
When to reach for an API instead of a tab
The browser is right for occasional work. But if you are converting the same kind of document on a schedule, or building a feature into your own app, you do not want a human clicking upload. That is the point where a free API pays off.
I have been using Convertica for both sides of this. The web tools cover the ad-hoc jobs (compress, merge, split, PDF to Word or Excel, unlock, and so on) with no signup, and there is an API for wiring conversions into a pipeline. A typical call is nothing more than a POST with the file:
curl -X POST https://convertica.net/api/v1/pdf-to-word/ \
-F "file=@report.pdf" \
-o report.docx
Uploaded files are removed from the server after a short window, which matters when the documents are statements or contracts rather than throwaway samples. For anything genuinely secret, I still generate the file from source rather than round-tripping it through any service, mine or otherwise.
A note on PDF passwords, since it trips people up
PDFs carry two kinds of password and they behave very differently. An open password encrypts the file: without it, nothing can read the content, and no tool bypasses real encryption in seconds regardless of what its landing page claims. A permissions password only disables copy, print, or edit while letting the file open, and that kind was never strong protection to begin with.
The practical takeaway for developers: if you need to actually secure a document, set an open password and share it out of band. Do not rely on permission flags, because most readers and libraries ignore them.
The shift, in one line
The work has not changed. Files still need to be smaller, mergeable, and machine-readable. What changed is that none of it requires a paid desktop install anymore. Occasional jobs go in a browser tab, repeated ones go through an API, and the only real prerequisite is that ten-second check of whether your PDF is text or a picture.
Top comments (0)