PDF extraction
Fax to PDF: A Developer's Guide for 2026
Why fax still hits production inboxes and how to build an ingestion pipeline that turns TIFFs and image-only PDFs into hosted, OCR'd, queryable documents.
You inherit a workflow that was supposed to be gone years ago. Instead, invoices arrive as fax images in an email inbox, referral packets land in a shared folder as TIFFs, and someone asks if your app can “just turn them into searchable PDFs.”
That request sounds small until you touch the files. Most faxes aren’t documents in the modern sense. They’re images of documents. No selectable text, no clean table structure, no reliable metadata, and often no consistent quality. The actual job isn’t converting fax to pdf. It’s turning a transport format from another era into something your system can index, extract, redact, and route.
Table of Contents
- Why You Still Need a Fax to PDF Workflow in 2026
- The Two Primary Fax to PDF Scenarios
- Quick Conversions for One-Off Faxes
- Building an Automated Fax to PDF Ingestion Pipeline
- Unlocking Data with OCR Redaction and AI Chat
- From Legacy Image to Live Data
Why You Still Need a Fax to PDF Workflow in 2026
A lot of teams still ask the wrong question. They ask why fax still exists. The better question is what to do with faxed documents once they hit your system.
Fax is still part of real production systems
Fax is still embedded in regulated workflows, especially where secure, traceable document exchange matters. The ACM reporting on fax persistence notes that the Global Fax Services Market was valued at $3.18 billion in 2022 and is projected to reach $5.96 billion by 2028, and that U.S. healthcare alone accounted for over 9 billion faxed pages in a single year. If you’re building for healthcare, legal, finance, or any adjacent vendor ecosystem, fax isn’t a historical curiosity. It’s an input channel.
That doesn’t mean you should preserve fax as-is. It means you need to absorb it cleanly.
Teams that are modernizing business faxing through email usually aren’t trying to celebrate fax. They’re trying to wrap a legacy transport layer in interfaces their staff and software can use. For developers, pdf becomes the first sane boundary. It gives you a stable file object, better sharing semantics, and a format that downstream OCR and extraction tools can handle.
Practical rule: Treat fax like an ingestion source, not a destination format.
The actual problem is image to data
A fax image can look acceptable to a human and still be useless to software. That’s the gap. Your app needs searchable text, fields, tables, timestamps, and sometimes redaction. Fax gives you none of that by default.
There are really two tracks:
| Situation | Best path |
|---|---|
| One-off document | Scan or convert it manually, save as pdf, verify readability |
| Recurring workflow | Build an automated pipeline that ingests, stores, OCRs, and routes the file |
The trade-off is simple. Manual conversion is fast to start and expensive to repeat. An API-driven flow takes setup time, but once it’s in place, every new fax follows the same path.
If your system only sees one fax a month, keep it simple. If your app receives faxes every day, build for repeatability.
The Two Primary Fax to PDF Scenarios
Not every fax to pdf job starts from the same place. That matters, because the first failure point is different depending on whether the document began on paper or arrived digitally.
Paper fax workflow
This is the old-school path. Someone receives a printed fax or a physical page that now needs to become a pdf.
The early mistakes happen at scan time. If the page is skewed, cropped too tightly, scanned with aggressive compression, or captured at low resolution, every later step gets harder. OCR quality drops. Tables fragment. Signatures blur. Handwritten notes disappear into background noise.
Use this path when the source is physical:
- Prepare the page. Flatten folds, remove staples, and scan pages in order.
- Choose settings for OCR, not just appearance. Grayscale usually works well for text-heavy pages.
- Export as one multi-page pdf. Don’t create a pile of separate image files unless your system explicitly needs them.
- Check one page before scanning the stack. It saves rework.
Digital fax workflow
This path is more common in current systems. An e-fax provider, email gateway, or PBX integration drops a file into your process. That file may be TIFF, JPG, PNG, or already a pdf with image-only pages.
The trap here is assuming “digital” means “clean.” It often doesn’t. You may get lossy compression, uneven page sizes, upside-down scans, or multi-page TIFFs that many general file handlers treat badly.
A quick comparison helps:
| Input type | Common issue | What to do first |
|---|---|---|
| TIFF | Multipage handling and inconsistent page metadata | Normalize into a single pdf |
| JPG or PNG | One file per page, compression artifacts | Reassemble pages in order before OCR |
| Image-only PDF | Looks like pdf, acts like a scanned image | Run OCR before extraction |
| Email attachment batches | Duplicate sends, naming collisions | Add deduping and timestamped storage |
A digital fax isn’t automatically machine-readable. It’s often just an image wrapped in a file type developers trust too much.
The rest of the implementation depends on which branch you’re in. Paper needs good capture discipline. Digital needs normalization discipline. Both need validation before extraction.
Quick Conversions for One-Off Faxes
If you just need to convert a fax to pdf once, don’t overbuild it. The right move is to produce a readable file, keep the page order intact, and make sure someone else can open it without hunting through attachments.
If the fax starts on paper
Use a flatbed or document feeder if you have one. Phone scans are fine for casual use, but they add perspective distortion and uneven lighting. That’s bad news if anyone needs OCR later.
A few settings matter more than people think:
- Use grayscale for text-heavy pages. It usually preserves legibility without inflating file size.
- Keep page order fixed at scan time. Reordering later is where mistakes creep in.
- Prefer a single multi-page pdf. It travels better through email, storage, and review tools.
- Inspect signatures and small print. Faxed legal and financial pages often fail there first.
If you already have image files
A lot of one-off jobs begin with a folder of JPGs or a fax attachment exported as images. In that case, the fastest path is to combine them into one pdf and stop there unless you need searchable text.
For a basic image-to-pdf step, a simple utility like convert JPG scans into a PDF is usually enough. The key is consistency. Put the pages in the right order before conversion, use sensible filenames, and confirm the output renders cleanly on desktop and mobile.
After conversion, share the resulting pdf as a proper file link, not as a chain of forwarded attachments. That sounds minor, but it avoids version drift.
Poor quality is where one-off conversions usually break
The hardest one-off faxes aren’t the long ones. They’re the ugly ones. Low resolution, streaking, speckles, faint thermal copies, and weird contrast make ordinary converters stumble.
The voip-info discussion of poor outgoing PDF fax quality highlights this gap and notes that up to 30% of failures in real-world hybrid systems stem from quality issues. That’s why a converter can appear to “work” but still produce a file no parser can use.
Use this checklist before you call the job done:
- Zoom to actual text size. If 8-point text is mushy on screen, OCR will struggle too.
- Check edge crops. Fax headers and right margins get clipped more often than people notice.
- Avoid repeated conversions. JPG to PDF to image to PDF compounds artifacts.
- Rescan if the source is available. Cleanup software helps, but a better first capture helps more.
If a fax looks barely readable to you, assume it will be worse for OCR.
For one-offs, that’s enough. Clean input. Single pdf. Quick review. Share the final file and move on.
Building an Automated Fax to PDF Ingestion Pipeline
Once faxes show up regularly, manual conversion becomes a tax on the team. The fix is to treat fax as another inbound document source, like email attachments or uploads from a customer portal.
What reliable inbound automation actually looks like
A practical automated pipeline usually has these stages:
- Receive the fax artifact from email, SFTP, object storage, or a fax provider webhook.
- Normalize the file into a predictable internal representation.
- Store a canonical pdf that other services can reference.
- Trigger follow-up work like OCR, extraction, routing, or review.
- Record status and retries so failed deliveries don’t disappear without notice.
The PMC study on automated fax workflows is useful here because it describes the pattern directly: professional inbound fax automation systems achieve a 98.7% delivery success rate after automated retries, and the core method is fax to TIFF, OCR preprocessing, then Ghostscript-based PDF conversion. You don’t need to reproduce that exact stack line for line, but the lesson is clear. Retry logic and normalization matter more than heroic cleanup at the end.
A simple ingest and host pattern
For developers, the first useful milestone isn’t extraction. It’s creating a stable hosted pdf object your system can reference by ID.
That pattern usually looks like this:
- your worker detects a new fax file
- it uploads the file once
- your app stores the returned
file_id - later jobs use that same ID for OCR, parsing, and review
A minimal curl example for an upload step could look like this:
curl -X POST "https://api.okrapdf.com/v1/files" \
-H "Authorization: Bearer $OKRAPDF_API_KEY" \
-F "file=@incoming-fax.pdf"And a JavaScript version in a server action or queue consumer:
import fs from "node:fs";
async function ingestFax(pathToFile) {
const form = new FormData();
form.append(
"file",
new Blob([fs.readFileSync(pathToFile)], { type: "application/pdf" }),
"incoming-fax.pdf"
);
const res = await fetch("https://api.okrapdf.com/v1/files", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.OKRAPDF_API_KEY}`
},
body: form
});
if (!res.ok) {
throw new Error(`Upload failed: ${res.status}`);
}
const file = await res.json();
return file;
}The response includes a durable file_id such as doc-.... Persist that ID in your own database and use it for parsing, page images, review, and downstream workflows. If the fax provider gives you TIFF or image files, normalize them to a PDF before this upload step.
Webhook driven status handling
Don’t poll if you don’t have to. Ingestion systems get simpler when later processing happens off events.
A clean setup looks like this:
| Event | Action |
|---|---|
| fax file received | Upload and create internal document record |
| pdf hosted | Mark file ready for OCR |
| ocr complete | Run extraction or human review |
| parse failed | Send to retry queue or exception bucket |
If you want callback-based orchestration, set up document processing webhooks so your app can react to state changes instead of sleeping and checking status.
Build it like mail processing, not like a user clicking buttons. Queues, retries, idempotency keys, and dead-letter handling matter more than a nice dashboard once volume arrives.
A lot of brittle fax systems fail because they bind ingestion and parsing into one synchronous request. Keep them separate. Upload first. Then do the expensive work.
Unlocking Data with OCR Redaction and AI Chat
Once the fax exists as a stable pdf in your system, conversion is over. The useful part starts there.
OCR first when the fax is image only
If the pages came from TIFF or image scans, OCR is the first downstream job. Without it, search doesn’t work, copy-paste doesn’t work, and most extraction quality will be poor.
For an OCR pass, the flow is straightforward:
curl -X POST "https://api.okrapdf.com/v1/parse" \
-H "Authorization: Bearer $OKRAPDF_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"file": { "id": "doc-..." },
"parser": "llamaparse",
"pages": "1",
"outputs": ["json"]
}'The parse response is a job object with a status_url. Poll that URL until status is succeeded, then read the parsed text, layout blocks, and page metadata from the job result.
If you want a browser-based starting point before wiring the API, an OCR PDF tool for scanned documents is a useful sanity check. It helps verify whether the issue is your ingestion code or the document itself.
Extract structure after the PDF is stable
A searchable pdf is good. Structured output is better.
For statements, invoices, referral forms, and intake packets, the next job is usually text or table extraction. Using the same file_id keeps your pipeline simple.
async function extractJson(fileId) {
const res = await fetch("https://api.okrapdf.com/v1/parse", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.OKRAPDF_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
file: { id: fileId },
parser: "llamaparse",
pages: "1",
outputs: ["json"],
schema: {
type: "object",
additionalProperties: false,
properties: {
sender: { type: "string" },
recipient: { type: "string" },
received_at: { type: "string" },
summary: { type: "string" }
},
required: ["summary"]
}
})
});
if (!res.ok) throw new Error("Parse job failed to start");
return res.json();
}For workflows that care about rows and columns, request CSV or structured JSON. For workflows that care about prose, request text or Markdown. The best format depends on what you do next, not on what looks convenient in a demo.
Redact before wider distribution
Faxed documents often carry names, account numbers, addresses, or medical context. If the file moves beyond the intake boundary, add redaction before broader sharing or model access.
The live upload and parse paths above are the stable API boundary. Redaction should be treated as a policy step on top of parsed coordinates and review decisions, not as a generic “mask all PII” call. Decide whether you want a review queue, automatic masking of known sensitive fields, or both before broader distribution.
Add chat only after the basics work
The interesting development in current fax automation isn’t just better conversion. It’s using the converted document as a queryable object. The 2025 healthcare middleware trend report points to this direction directly, noting that the next frontier is chaining fax-to-PDF conversion with AI chat capabilities through a single file ID architecture.
That makes sense. Once a fax is hosted, OCR’d, and optionally redacted, you can expose it to support agents, operations staff, or internal tools as a document they can ask questions about.
Conceptually:
async function askDocument(fileId, question) {
const res = await fetch(`https://api.okrapdf.com/v1/documents/${fileId}/chat/completions`, {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.OKRAPDF_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
messages: [
{ role: "user", content: question }
]
})
});
if (!res.ok) throw new Error("Chat request failed");
return res.json();
}Use this after you’ve solved OCR quality, extraction reliability, and access control. AI chat is useful. It isn’t a substitute for a sane ingestion pipeline.
From Legacy Image to Live Data
Fax to pdf isn’t really a file conversion problem. It’s an operational boundary problem. You’re taking a legacy document transport, normalizing it into a usable asset, and deciding what your software can safely do next.
For a single incoming fax, the lightweight route works. Scan carefully, combine pages cleanly, inspect the output, and share the final pdf. That’s enough when the volume is low and the stakes are modest.
For product teams and internal platforms, that manual path doesn’t hold. You want an ingestion pipeline that accepts TIFFs, images, or fax attachments, creates one canonical pdf, stores a stable document ID, and then fans out to OCR, extraction, redaction, and review. That’s where fax stops being a dead-end image and starts behaving like application data.
If your end goal is accounting or reconciliation, guides on workflows like financial auditing via PDF to Excel are useful because they show the final business use case. The developer job sits one layer earlier. You make sure the fax enters the system in a form those workflows can trust.
The good news is that fax persistence doesn’t force you into legacy architecture. You can keep the transport requirement and still build a modern document pipeline around it.
If you’re building that pipeline, start with okraPDF. Upload once, get a stable file_id, host the pdf, then layer on extraction, sharing, and downstream document workflows without re-uploading the file.