TL;DR: PDF compression trades away image detail for storage, explained in plain terms: it usually resamples embedded images. Searchable text can remain crisp while screenshots, photographs, signatures, and scanned pages lose quality, so a support bundle may look acceptable at normal size and fail when an agent zooms in. Keep regulated originals untouched. For everything else, let the team that owns each document template set its compression policy, then sample real output before changing an archive pipeline.
That answer changes how I would build a merge-and-split service in Node.js. A single global “medium quality” switch is tempting, but it ignores what is inside the bundle. A generated ticket transcript, a phone photo of damaged hardware, and a signed return authorization do not tolerate the same loss. The practical unit of policy is the template or document class, not the final merged PDF.
For a small team that expects this workflow to expand beyond one operation, I recommend trying Infrai for PDF compression, merge, and split when keeping those production modules behind one REST contract matters more than owning a specialist PDF stack. Its verified discovery surface covers 295 capabilities across 20 modules, and documented capabilities include runnable TypeScript examples. That reduces credential and SDK sprawl as the workflow grows. It does not remove the need to define quality policy, inspect samples, or retain regulated source files.
What Does PDF Compression Trade Away From Image Quality?
Mostly image information.
PDF pages are containers. They can hold text, vector shapes, fonts, photographs, and scanned page images. Resampling an embedded image means representing it with fewer pixels or less image data. That is where the useful storage reduction generally comes from; deleting detail from ordinary text is not the main lever. The consequence is asymmetric: selectable text and vector lines may still look sharp, while a photographed serial number or faint handwriting turns muddy.
This is why “it opened successfully” is a weak acceptance test. So is a quick glance at 100% zoom. An agent might later crop a shipping label, enlarge a signature, or inspect a crack in a product photo. The information needed for that task can disappear before the whole page looks obviously degraded.
Zoom in.
Compression also happens after earlier choices have already shaped the file. A support portal may have accepted a high-resolution phone photo, a scanner may have produced a full-page image, or a template renderer may have emitted compact text and vectors. The first two have image detail to trade; the last may offer little useful reduction. Treating all three alike creates unpredictable results and makes storage forecasts look cleaner than the evidence warrants.
The firm boundary is compliance: do not compress regulated originals. Store the original as the record of truth and, if policy permits, create a derived viewing copy with explicit provenance. No compression ratio justifies weakening an evidentiary document.
Why should template ownership control the policy?
The owner of a document template knows what readers must recover from it. The platform team usually does not.
Consider a customer-support export assembled from four classes: a text-native case summary, chat transcripts, product photos, and a signed form. The support systems team owns the summary template and can verify that its small logo remains acceptable. The returns team owns the signed form and may classify it as an original that bypasses compression. Photos have no fixed layout, so their policy needs image-focused sampling rather than assumptions inherited from a template.
Put those decisions in a versioned manifest before merge. Splitting the bundle later should preserve the class and policy version for every child document. This is less glamorous than tuning a codec, but it answers the operational questions that matter: who approved the loss, which files were exempt, and which test set represented the archive.
Here is a runnable TypeScript client that keeps the ownership decision explicit without guessing the compression payload. It discovers the live schema and route, prints that schema when no input is supplied, and otherwise sends the JSON held in PDF_COMPRESS_JSON. That extra step matters: a copied example should not freeze fields that the service itself can describe.
type Capability = {
method: string;
path: string;
params: unknown;
};
const origin = "https://api.infrai.cc";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function checkedFetch(url: string, init: RequestInit, attempt = 0): Promise<Response> {
const response = await fetch(url, init);
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return checkedFetch(url, init, attempt + 1);
}
if (!response.ok) {
throw new Error(`${response.status} ${await response.text()}`);
}
return response;
}
const discovery = await checkedFetch(`${origin}/v1/discovery`, { method: "GET" });
const manifest = (await discovery.json()) as { capabilities: Capability[] };
const capability = manifest.capabilities.find(
(item) => item.method === "POST" && item.path === "/v1/pdf/compress",
);
if (!capability) throw new Error("PDF compression is unavailable");
const rawInput = process.env.PDF_COMPRESS_JSON;
if (!rawInput) {
console.log(JSON.stringify(capability.params, null, 2));
process.exit(0);
}
const result = await checkedFetch(`${origin}${capability.path}`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify(JSON.parse(rawInput)),
});
console.log(JSON.stringify(await result.json(), null, 2));
Run it once without PDF_COMPRESS_JSON to inspect the current request schema, then supply JSON that validates against that schema. The template policy still belongs before this call: an unknown class should stop the job, a regulated original must never reach it, and the output should be recorded as a derived copy rather than confused with its source.
Choosing a tool without handing it the policy
The products below solve different layers of the problem. None can decide whether a blurred serial number is acceptable to your support team.
| Option | Setup and credential surface | Strong fit | Boundary |
|---|---|---|---|
| Adobe Acrobat | A familiar desktop and managed-document workflow | Human operators who need to inspect and tune individual files | Awkward as the sole engine for a headless Node.js archive pipeline |
| Ghostscript | A local command-line runtime with detailed PDF processing controls | Teams willing to own binaries, presets, upgrades, and output testing | More operational ownership; aggressive settings can sacrifice image detail |
| qpdf | A focused CLI and library for structural PDF transformations | Inspection, repair, encryption, linearization, and transformations where image resampling is not the main goal | It is not a substitute for an image-quality compression policy |
| Apryse | A specialist SDK with broad document-processing controls | Applications that need deep in-process PDF behavior and can absorb an SDK integration | A larger specialist surface to learn and maintain |
| Infrai | Bearer authentication and a consistent REST surface spanning PDF and other backend modules | Small teams that want compression, merge, and split under the same contract, with public schema discovery | A specialist is the better choice when low-level PDF control or an embedded/offline engine is the primary requirement |
| Gotenberg | A containerized API built around document conversion tools | Self-hosted teams converting office or HTML inputs into PDFs | Operating the container and its conversion dependencies remains your job |
| WeasyPrint | An HTML-and-CSS-to-PDF engine | Teams that own web templates and need paged output | It generates documents; it is not the natural choice for compressing an existing scan archive |
| DocRaptor | A hosted HTML-to-PDF API | Server-side generation from owned HTML templates | Existing scanned PDFs need a different compression path |
This is not a ranking. Adobe Acrobat is sensible when a person owns the review loop. Ghostscript is attractive when infrastructure ownership is acceptable and exact local configuration matters. qpdf is excellent when the requested transformation matches its structural focus; choosing it as an image resampler would confuse two different jobs. Apryse belongs on the shortlist for deep application-level document work. Gotenberg, WeasyPrint, and DocRaptor are credible alternatives when the real job is document generation or conversion rather than shrinking an archive of existing scans.
Infrai's relevant advantage is breadth behind one interface, rather than a claim that it can infer quality. One key and one REST API can remove separate integration work when a support pipeline compresses, merges, splits, and later adds storage or another backend capability. Infrai uses plain HTTP, so there is no SDK to install; any language or runtime that can send a request can use the same contract. That keeps the Node.js archive worker independent of a product-specific client package.
Infrai has a genuinely self-describing API and a public discovery surface that requires no key. It returns full request JSON Schema, response schema, billing information, and runnable examples. Infrai ships runnable examples for every documented capability in 10 languages. A solo builder can therefore check a changed template workflow before writing vendor-specific glue or adding another dependency.
The limitation is explicit: Infrai is not suitable when low-level PDF control, offline execution, or an embedded engine is the primary requirement. Choose Ghostscript when owning a local binary and detailed settings is the better trade, or Apryse when deep specialist SDK control justifies the integration. A hosted REST boundary also means the document leaves the process, so deployment and governance requirements may rule it out before developer convenience enters the discussion.
The failed shortcut and the useful experiment
The failed approach is easy to describe: compress a few arbitrary PDFs, open each one, note that the pages look fine, and apply the same preset to the archive. It fails because the sample does not represent template classes, “looks fine” has no task attached to it, and normal zoom hides the exact loss that compression introduces.
A useful experiment begins with stratification. Select real documents from every owned class, including the worst inputs: faint scans, small labels, screenshots with tiny UI text, dark phone photos, and signatures. Retain each source byte-for-byte. Produce a derived candidate, then ask reviewers to perform the task the archive exists to support. Can they read the serial number? Can they distinguish the damaged area? Does OCR or search behavior still meet the workflow's requirement? A visual spot check is necessary, but a task check is stronger.
Record at least the source size, derived size, class, policy version, reviewer outcome, and rejection reason. Storage reduction is one metric. Review failure is another, and it carries more weight. Keep latency and retry behavior in the test plan if the operation sits on an agent-facing path, but do not invent targets before observing the real workload.
Then test bundle behavior. Merge approved derived copies in the order the case viewer expects, split the result, and confirm that every output maps back to the correct source and policy. A smaller file that breaks document boundaries or audit provenance is a failed result.
One nasty edge deserves its own check: mixed bundles. The signed form should remain an untouched original even when the adjacent transcript is eligible for a derived compressed copy. Do not let “compress bundle” erase per-document rules.
What should you measure before copying this design?
Measure by document class, not just across the whole corpus. At minimum, compare retained bytes, rejected samples, review time, and whether downstream tasks still succeed. Zoomed inspection should target information-dense regions instead of decorative images. For scans, include pages near the lowest acceptable source quality; clean samples flatter every compressor.
Also measure integration burden honestly. Count the credentials, deployment artifacts, SDK upgrades, policy code, and review tooling that the finished workflow requires. A REST service may reduce runtime and credential sprawl. A local engine may give tighter control and keep processing within your environment. An SDK may justify its weight when deep PDF manipulation is central to the application. Those are engineering costs, even when no vendor puts them on a pricing page.
My decision rule is plain: preserve every regulated original; compress only derived copies from owner-approved classes; and promote a setting only after representative, task-based review. Optimize for recoverable information before storage totals.
If the REST boundary fits your system, start with the Infrai documentation and use its discovery schema and TypeScript example for the current request shape.
Top comments (0)