Skip to main content

​
Boundaries

​
Two different limits: raw vs storage URL

The raw upload (body of /convert/raw) has its own and much lower limit (12 MB) than the processing limit (500 MB). The raw travels through the entire network before starting to convert, so a huge body spends seconds just transferring. That’s why:
  • PDF small → /convert/raw direct.
  • PDF large → upload it to your storage and use /convert/from-url or /convert/accelerated, which do not apply the raw limit (still FETCH_MAX_BYTES, 500 MB).
Detail and size table in Raw vs storage URL.

​
What happens when you overcome them

  • Raw upload above RAW_UPLOAD_MAX_BYTES → 413 with a useful JSON body (error, max_raw_upload_mb, why, recommendation, recommended_endpoint) that tells you how to do it right. The bug never leaks the signed URL or internal paths.
  • Document or download above MAX_INPUT_BYTES/FETCH_MAX_BYTES → 413.
  • PDF with more pages than the limit → 413.
  • ZIP with too many entries or too large member → 413.
The raw limit is measured over decompressed bytes: a gzip/zstd body that decompresses above the limit is also rejected.
You can raise the raw limit with RAW_UPLOAD_MAX_BYTES, or disable it completely with ALLOW_LARGE_RAW_UPLOAD=true (reverts to MAX_INPUT_BYTES). In general it is not worth it: for large files, from-url is faster.

​
Recommendations

  • For very large documents, upload to your storage and use /convert/from-url: avoid resending bytes.
  • Compress the upload with gzip or zstd in /convert/raw.
  • Split huge documents into logical parts if you only need sections.
The real value to an agent is in responding quickly with useful Markdown, not in accepting the largest file possible.