Skip to main content

​
Compresión de subida

POST /convert/raw acepta el cuerpo comprimido. Reduces bytes en red y aceleras subidas grandes. Indica el algoritmo con el header content-encoding.
Solo /convert/raw soporta content-encoding. /convert (multipart) y /convert/from-url no.

​
gzip

​
zstd

​
Recomendaciones

  • Para uploads grandes, zstd suele dar el mejor equilibrio ratio/CPU.
  • Evita Brotli: ahorra bytes pero consume mucha más CPU.
  • El header X-Wire-Bytes te dice cuántos bytes llegaron por red tras comprimir; X-Input-Bytes, el tamaño real descomprimido.
Un content-encoding distinto de gzip o zstd responde 415.

​
Compresión de SALIDA (output_encoding)

Cuando usas output_url en /convert/from-url, el Markdown convertido se sube comprimido a tu storage. El parámetro output_encoding controla el algoritmo: Cuando hay output_url, la API auto-promueve a zstd si no especificas otro. Razón: en el caso BYOS no hay browsers ni CDNs en el camino; cliente y servidor son backends que descomprimen zstd nativo. zstd resulta en ~30% menos bytes que gzip a CPU similar y descompresión en streaming en el cliente. Sobreescribir es trivial:

​
El límite de raw mide bytes descomprimidos

El límite de upload crudo (RAW_UPLOAD_MAX_BYTES, 12 MB por defecto) se aplica sobre el tamaño descomprimido, no sobre los bytes que viajan por la red. Comprimir no te deja subir un PDF más grande por /convert/raw: un cuerpo gzip/zstd que descomprime por encima de 12 MB se rechaza con 413. La compresión solo ahorra red y tiempo de subida. Para PDFs grandes, súbelos a tu storage y usa /convert/from-url, que no aplica este límite. Ver Límites y Raw vs storage URL.