DEV Community: Convertica

Automating the PDF Conversions You Keep Doing by Hand

Convertica — Tue, 14 Jul 2026 13:48:34 +0000

Most PDF work is a one-off: a file lands, you convert it, you move on. But some of it repeats. A folder of scanned invoices every Monday. Statements that need to become spreadsheets before month-end. Reports that arrive as PDF and have to go out as Word. If you are doing the same conversion by hand every week, that is a job for a script, not a person.

Here is how I moved those repeat conversions off my plate.

First, the ten-second check that saves you

Before automating anything, know which kind of PDF you are feeding the pipeline. Select a word in the file. If it highlights, the text is real and conversion is clean and deterministic. If nothing highlights, the page is an image, and you need OCR in the loop, which is still fine but adds a recognition step you should spot-check. Automations break most often because someone assumed every input was a native PDF when half of them were scans.

Wrapping a converter in a script

The pattern is boring in the best way: watch a folder or a queue, POST each file to a conversion endpoint, write the result somewhere. I use Convertica for the conversion step because it has a free API and does not require an account, so there is no OAuth dance to script around. A single conversion is just a POST with the file:

curl -X POST https://convertica.net/api/v1/pdf-to-word/ \
  -F "file=@invoice.pdf" \
  -o invoice.docx

Drop that into a loop and a cron entry and the Monday-invoices chore runs itself:

#!/usr/bin/env bash
set -euo pipefail
IN=./incoming
OUT=./converted
mkdir -p "$OUT" "$IN/done"
for f in "$IN"/*.pdf; do
  name=$(basename "${f%.pdf}")
  curl -fsS -X POST https://convertica.net/api/v1/pdf-to-excel/ \
    -F "file=@${f}" -o "${OUT}/${name}.xlsx" \
    && mv "$f" "${IN}/done/"
done

# every Monday at 6am
0 6 * * 1 /home/me/scripts/convert-invoices.sh >> /var/log/convert.log 2>&1

The set -euo pipefail and curl -fsS matter more than they look. Without them a failed conversion writes a zero-byte file, your mv marks it done, and you lose the input silently. Fail loudly instead.

The parts people skip

Idempotency. Move processed files out of the input folder (or track them) so a re-run does not convert the same file twice.
Scanned inputs. If the batch might contain scans, expect OCR and add a sanity check on the output. A zero-length or suspiciously tiny result usually means a bad scan.
Cleanup. Whatever service you use, know its retention. Convertica deletes uploads from the server after a short window, which is what you want for statements and contracts rather than throwaway samples.
Secrets stay home. For genuinely confidential documents I generate the file from source rather than round-tripping it through any external service, mine included. Automation is for the routine stuff, not the crown jewels.

Do not forget the passwords

One thing that quietly breaks batch jobs: a password-protected PDF in the input. There are two kinds, and they fail differently. An owner-password file (restrictions only) usually still converts. An open-password file is encrypted and will not convert without the password, and no tool bypasses real encryption, so your script should catch that case and set the file aside for a human rather than retrying forever.

The point

The work has not changed. Files still need to be smaller, converted, and machine-readable. What changed is that the repetitive slice of it belongs in a five-line script and a cron entry. Spend the ten seconds to check text-versus-scan, fail loudly, respect retention, and the Monday chore stops being a chore.

PDF Chores You No Longer Need a Desktop App For

Convertica — Tue, 14 Jul 2026 12:49:03 +0000

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.