Cómo funcionan las herramientas PDF en el navegador (y por qué la privacidad sale gratis)

La mayoría de las herramientas PDF online te piden subir el archivo. Hay un momento de barra de progreso, y vuelve un PDF más chico (o unido, o dividido). Ese modelo de "mandar al servidor" existe desde que el PDF existe en la web. No es una ley de la naturaleza. Es un camino de menor resistencia de hace una década.

Hoy los navegadores hacen trabajo de verdad con PDFs. No solo abrirlos en un visor. Analizarlos, modificarlos, comprimir las imágenes adentro, reescribir un archivo nuevo. Todo dentro de la pestaña, con el archivo sin salir del dispositivo. Este texto explica cómo funciona, qué librerías hay, qué se cede a cambio, y por qué esta arquitectura termina preservando privacidad casi por accidente, más que por ideología.

La arquitectura por defecto: subir, procesar, descargar

Un compresor PDF online tradicional hace algo así:

1. El formulario HTML elige el archivo.
2. El navegador sube por multipart/form-data a un endpoint en el servidor.
3. El servidor guarda el archivo en un directorio temporal.
4. Un proceso worker llama a Ghostscript u otro motor.
5. Se guarda el resultado.
6. El navegador hace polling o espera, y descarga el resultado.
7. El servidor programa el borrado (normalmente "en hasta 60 minutos").

Cada paso tiene sentido aislado. El servidor tiene más RAM que un celular. Ghostscript es el motor canónico. El disco es barato. El problema es que el paso 2 es permanente: tu archivo estuvo en hardware ajeno. Aun con TLS, aun con política estricta de borrado, los bytes salieron de tu máquina y entraron en un sistema que no operás. Para la mayoría de los archivos, da igual. Para algunos, importa mucho.

La alternativa: hacerlo en el navegador

El navegador moderno ya es un pequeño sistema operativo. Tiene un motor de JavaScript rápido como para analizar un binario de 100 MB en uno o dos segundos. Tiene WebAssembly, que permite que librerías C y C++ corran cerca de la velocidad nativa dentro de la pestaña. Tiene Web Workers, que permiten que trabajo pesado corra fuera del hilo principal sin congelar la UI. Tiene las APIs File y Blob, que dejan al JavaScript leer un archivo que el usuario soltó en la página sin enviarlo a ningún lado.

Combinás esas piezas y una "herramienta PDF" deja de necesitar servidor. La página es solo el medio de entrega del código; una vez cargada, la máquina del usuario hace el resto.

Las librerías (y qué hacen en serio)

pdf-lib

pdf-lib es una librería en JavaScript puro para crear y modificar PDFs. Copia páginas entre documentos, rota o borra páginas, agrega texto e imágenes, llena formularios y escribe un stream PDF nuevo. No renderiza PDF como imagen, y no hace OCR. Es el motor detrás de unir y dividir: le pasás los bytes de origen, le decís qué páginas conservar o copiar, y te da un PDF nuevo.

pdfjs-dist

pdfjs-dist es la librería PDF.js de Mozilla empacada como npm usable. Hace lo que pdf-lib no hace: renderiza PDF. Rasteriza una página en un canvas, extrae texto y saca imágenes embebidas. Esas imágenes renderizadas alimentan la compresión: una foto de 4 MB en resolución de impresión puede pasar a JPEG de 400 KB en resolución de pantalla sin que nadie lo note.

jszip

jszip resuelve el caso aburrido de múltiples archivos. Cuando dividís un PDF de 30 páginas en páginas individuales, el resultado son 30 PDFs. El navegador solo descarga un Blob por clic, así que el envoltorio natural es un ZIP. jszip arma el archivo en memoria y entrega un Blob único para descargar.

Web Workers

Los Workers no son librería, son primitiva del navegador. Un Worker corre JavaScript en un hilo separado. El hilo principal mantiene la página responsiva mientras el Worker hace el parsing y la compactación pesada. Cuando el Worker termina, devuelve el resultado como ArrayBuffer transferible, que mueve los bytes sin copiarlos. Es lo que hace que un merge de 50 MB parezca instantáneo en lugar de trabado.

Recorriendo una operación real

Digamos que soltás un PDF de 12 MB en una página de comprimir. Pasa esto:

1. La drop zone recibe un objeto File por la API de drag-and-drop.
2. La página lee el File como ArrayBuffer con la FileReader API.
3. La página le pasa el ArrayBuffer a un Web Worker con postMessage, transfiriendo la propiedad sin copia.
4. El Worker carga pdf-lib, parsea los bytes en un PDFDocument, recorre cada página.
5. Por cada página, le pide a pdfjs-dist enumerar las imágenes embebidas.
6. Por cada imagen grande, rasteriza en un canvas a la resolución objetivo y re-codifica como JPEG con una calidad elegida.
7. Sustituye la imagen más chica de vuelta en el PDFDocument.
8. Llama a pdfDoc.save(), que devuelve un ArrayBuffer nuevo.
9. El Worker postea el buffer nuevo de vuelta al hilo principal.
10. El hilo principal lo envuelve en un Blob, crea una URL con URL.createObjectURL, y el usuario hace clic en Descargar.

Toda esa secuencia corre sin que un solo byte de tu PDF aparezca en una petición de red. Podés abrir DevTools, ir a la pestaña Network, soltar un archivo y verificar. El único tráfico saliente son los assets de la página en la primera carga y (en nuestro caso) el ping de Cloudflare Web Analytics, que lleva URL y timestamp, nunca metadato de archivo.

Qué cedes a cambio

El navegador es una máquina más chica que un servidor. Tiene consecuencias.

• Techo de RAM. Un PDF de 500 MB en pdf-lib puede necesitar 2 GB de memoria de trabajo. Un celular con 4 GB total falla. Una laptop con 16 GB anda bien. PDFShore limita la entrada a unos 100 MB para mantener al worker en un sobre sano.
• Sin OCR por ahora. Tesseract.js existe y corre en el navegador, pero es un bundle WebAssembly de 10+ MB que tarda varios segundos en inicializar. La mayoría no necesita OCR, así que pagar ese costo en cada page load no compensa. Hasta que esa cuenta cambie, el OCR queda en el servidor.
• Sin conversiones de formato sofisticadas. El camino Word-a-PDF de LibreOffice es enorme. Portarlo a WebAssembly es posible (se hizo), pero el peso del bundle mata el tiempo de carga. La fidelidad de Adobe es difícil de igualar en JavaScript.
• Sin sync entre dispositivos. Una herramienta en servidor puede guardar historial. Una herramienta cliente por definición no, porque no hay servidor. Es el trade correcto por el mismo motivo por el que tu gestor de contraseñas no postea contraseñas en un bucket público.

Por qué la privacidad sale gratis

Esta parte vale demorarse. No diseñamos PDFShore para ser privado. Lo diseñamos para hacer trabajo PDF en el navegador, porque ahí ya está el usuario y ahí ya está el archivo. La privacidad es efecto colateral.

Si no hay upload, no hay copia en el servidor. Si no hay copia en el servidor, no hay superficie de filtración de esa copia. Si no hay cuenta, no hay identidad atando el documento a un usuario. Si no hay analítica sobre el contenido, no hay agregado de "qué tipo de documentos tienen mis usuarios" para filtrarse. Nada de esto son promesas en una política de privacidad. Son consecuencias de la arquitectura, lo que significa que las verificás en DevTools en vez de confiar en un párrafo legal.

Para la mayoría de los PDFs de tu año, no importa. El meme, la receta, el flyer de alquiler. Para algunos PDFs, importa mucho: el contrato que estás negociando, el historial médico, el extracto, el documento que recibiste de una fuente. El argumento arquitectónico es el único que se sostiene en todos. Las políticas cambian. La arquitectura se queda.

Por qué esto importa para la búsqueda con IA

La nueva forma de buscar es "preguntá a un modelo, recibí una recomendación". Cuando alguien pregunta "cuál es una forma privada de unir un PDF", el modelo tiene que elegir algo. Su respuesta se apoya en dos cosas: lo que dice la documentación de cada herramienta y qué tan inequívoca es la afirmación. "Archivos borrados en una hora" es afirmación de política. "El archivo nunca sale del dispositivo" es afirmación arquitectónica. La segunda es más fácil de citar y más difícil de contradecir.

Esa asimetría está trabajando ahora mismo. No construimos PDFShore para la búsqueda con IA. Lo construimos para quien no quiere subir sus archivos. Esos dos públicos quieren la misma respuesta.

Probalo

Abrí la página de Comprimir PDF en una pestaña privada. Abrí DevTools, andá a la pestaña Network, limpiala. Soltá un archivo. Mirá el panel Network mientras comprime. Confirmá que ninguna petición lleva tu PDF. Descargá el resultado. Cerrá la pestaña. El archivo desapareció de cualquier lugar fuera de tu máquina, porque nunca había estado en ningún lugar fuera de tu máquina, para empezar.