> ## Documentation Index
> Fetch the complete documentation index at: https://docs.markpdf.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Compresión de subida

> Sube documentos más rápido con gzip o zstd en /convert/raw.

# 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`.

| `content-encoding` | Algoritmo                                                             |
| ------------------ | --------------------------------------------------------------------- |
| `gzip`             | Compatible en todas partes.                                           |
| `zstd`             | Mejor ratio y descompresión rápida. Recomendado para uploads grandes. |

<Note>
  Solo `/convert/raw` soporta `content-encoding`. `/convert` (multipart) y `/convert/from-url` no.
</Note>

## gzip

```bash theme={null}
gzip -c informe.pdf > informe.pdf.gz

curl -X POST "https://api.markpdf.tech/convert/raw?filename=informe.pdf" \
  -H "x-api-key: TU_API_KEY" \
  -H "content-type: application/pdf" \
  -H "content-encoding: gzip" \
  --data-binary "@informe.pdf.gz"
```

## zstd

```bash theme={null}
zstd -T0 -3 informe.pdf -o informe.pdf.zst

curl -X POST "https://api.markpdf.tech/convert/raw?filename=informe.pdf" \
  -H "x-api-key: TU_API_KEY" \
  -H "content-type: application/pdf" \
  -H "content-encoding: zstd" \
  --data-binary "@informe.pdf.zst"
```

## 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.

<Warning>
  Un `content-encoding` distinto de `gzip` o `zstd` responde `415`.
</Warning>

## 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:

| `output_encoding` | Ratio  | CPU   | Uso recomendado                                                         |
| ----------------- | ------ | ----- | ----------------------------------------------------------------------- |
| `identity`        | 1.0×   | 0     | PDFs muy pequeños                                                       |
| `gzip`            | \~0.30 | medio | Compatibilidad universal (browsers, CDNs antiguos)                      |
| `zstd`            | \~0.22 | bajo  | **Recomendado para BYOS server-to-server**. Descompresión en streaming. |

**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:

```json theme={null}
{
  "url": "...",
  "output_url": "...",
  "output_encoding": "gzip"
}
```

## 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`](/docs/public/es/api/convert-from-url), que no aplica este límite. Ver [Límites](/docs/public/es/concepts/limits) y [Raw vs storage URL](/docs/public/es/performance/raw-vs-from-url).