PDF to DOCX API
PDF in, editable Word out, still looking like the PDF it came from.
- Client
- AD VERBUM
- Year
- 2026
- Status
- Live
- My role
- Sole engineer
Problem
Converters give you one of two bad outcomes. Either a picture of the page, which cannot be edited, or a wall of unformatted text, which has lost the layout. Translation work needs both the words and the shape.
Architecture
- 01
Route each page
A detector decides per page whether the content is born-digital or scanned. That single decision is the entire cost model, so it is the most carefully tested code in the service.
- 02
Rebuild natively
Digital pages are reconstructed with PyMuPDF and python-docx into real Word constructs: headings, lists, tables, form boxes, and live fields for page numbers and the contents list.
- 03
Vision only when needed
Scanned pages, and only scanned pages, go to Claude vision. Everything else never touches a model.
- 04
Serve it
A web UI plus a REST API with per-key scoping and thirty-day retention. No database; files live under a data directory.
- 05
Deploy
GitHub Actions builds, pushes to ECR, and rolls onto a single small EC2 instance with in-flight requests drained before the swap.
Impact
Model cost is spent only on pages that genuinely need vision
Output opens in Word as an editable document, not an image
One t3.medium runs the whole service, deliberately single-worker