Documentation

Resource limits and hostile input

Decoded-stream and cache budgets guard the parser against decompression bombs. Raise them for large PDFs or lower them to harden against untrusted input.

By default a single stream may decode to at most 256 MB, a guard against decompression bombs, and one open document keeps at most 64 MB of rebuildable caches. Raise them for legitimately large PDFs, or lower them to harden against hostile input.

limits.go

// A single stream decodes to at most 256 MB by default, guarding against
// decompression bombs. Raise it for legitimately large PDFs, or lower it to
// harden against hostile input.
gopdfrab.SetLimits(gopdfrab.Limits{
	MaxDecodedStreamBytes: 512 << 20, // 512 MB
	MaxResidentBytes:      32 << 20,  // caches one open document keeps (default 64 MB)
})

gopdfrab.CurrentLimits()  // the effective caps
gopdfrab.DefaultLimits()  // the built-in caps

The caps are process-wide

They are enforced deep in the decode path, reached from many callers that hold no document handle, so one value applies uniformly rather than per call. Set them once at startup, before any concurrent verify or convert. A zero or negative field resets that cap to its default.

If you accept PDFs from users, treat these as part of your threat model rather than as tuning knobs. A few kilobytes of well-crafted PDF can ask a naive parser to allocate gigabytes, and depth caps exist for the same reason — deeply nested or circular object graphs are cheap to write and expensive to follow.

Nothing is silently truncated when a cap is hit. Exceeding a limit is reported, so a document that legitimately needs more room is distinguishable from one that is attacking you.