Cómo funciona la edición de PDF basada en el navegador (y por qué la privacidad es importante)

Cada vez que subes un documento a una herramienta PDF en la nube, ese documento se encuentra en servidores que no controlas, procesado por software que no puedes inspeccionar y almacenado por una empresa con sus propias políticas de retención y seguridad de datos. Durante un breve periodo, la infraestructura de otra persona alberga tus contratos, declaraciones de impuestos, historiales médicos o documentos comerciales confidenciales.

LuraPDF funciona de forma diferente. Todo sucede en la pestaña de tu navegador, en tu hardware, con la gestión de memoria de tu sistema operativo. Este artículo explica la arquitectura técnica que lo hace posible y las implicaciones técnicas que conlleva.

El navegador como plataforma de procesamiento de documentos

Los navegadores modernos ya no son solo renderizadores de HTML. Son entornos completos de ejecución de aplicaciones que incluyen:

• Motor JavaScript (V8 en Chrome, SpiderMonkey en Firefox): ejecuta el código a una velocidad casi nativa.
• WebAssembly (WASM): ejecuta código C/C++ compilado a una velocidad casi nativa dentro de un entorno aislado.
• API de Canvas: permite la manipulación de imágenes a nivel de píxel.
• API de acceso al sistema de archivos: permite leer archivos locales sin necesidad de subirlos.
• Web Workers: ejecuta cálculos en subprocesos en segundo plano sin congelar la interfaz de usuario.
• ArrayBuffer / Blob: gestiona datos binarios sin procesar (como bytes de PDF) en memoria.

En conjunto, estas capacidades permiten un sistema completo de procesamiento de documentos que hace cinco años habría requerido un servidor backend.

Las tres bibliotecas principales

LuraPDF se basa en tres bibliotecas fundamentales de código abierto:

pdf-lib

pdf-lib es una biblioteca de TypeScript para crear y modificar documentos PDF en cualquier entorno JavaScript. Implementa una parte sustancial de la especificación PDF (ISO 32000), que incluye:

• Creación, modificación y eliminación de páginas
• Incrustaciones de fuentes (tanto fuentes estándar de 14 bits como fuentes TTF/OTF personalizadas)
• Incrustaciones de imágenes (JPEG, PNG)
• Ubicación de las anotaciones de texto
• Creación y manipulación de campos de formulario
• Metadatos del documento (título, autor, fecha de creación, etc.)
• Cifrado de PDF (AES-128 y AES-256)
• Gestión de tablas de referencias cruzadas

Cuando LuraPDF combina archivos PDF, utiliza pdf-lib para leer la estructura de páginas de cada documento, normalizar los recursos compartidos y crear un nuevo PDF. Al comprimir, recodifica los objetos de imagen con factores de calidad inferiores. Al cifrar, aplica AES-256 al documento mediante la API Web Crypto.

pdf-lib opera exclusivamente con objetos ArrayBuffer: datos binarios sin procesar en la memoria del navegador. No se realizan llamadas de red.

pdfjs-dist

PDF.js es el motor de renderizado de PDF de Mozilla, distribuido como pdfjs-dist en npm. Es el motor que impulsa el visor de PDF integrado de Firefox, probado con millones de archivos PDF reales.

LuraPDF utiliza pdfjs-dist para:

• Renderizado de página: Conversión de páginas PDF a Canvas ImageData para su visualización.
• Extracción de texto: Lectura de los flujos de contenido de texto de las páginas PDF.
• Metadatos de la página: Obtención de las dimensiones de la página, los valores de rotación y el tipo de contenido.

Cuando ves tu PDF renderizado en la interfaz de LuraPDF (la vista previa visual de las páginas), eso es pdfjs-dist renderizando cada página en un elemento Canvas de HTML.

Tesseract.js

Tesseract.js es la versión compilada con WebAssembly de Tesseract OCR. Tesseract es un motor OCR de código abierto desarrollado originalmente por HP Labs (1985) y mantenido actualmente por Google. Utiliza un modelo de red neuronal LSTM (memoria a largo y corto plazo) para el reconocimiento de caracteres.

Ejecutar Tesseract a través de WebAssembly en el navegador significa:

• El archivo binario WASM de 22 MB se carga una sola vez y el navegador lo almacena en caché.
• El procesamiento OCR se ejecuta en la CPU mediante WebAssembly, no en la GPU.
• El procesamiento es más lento que el OCR en la nube (que utiliza clústeres de GPU), pero produce un resultado de la misma calidad.
• El contenido de tus documentos nunca sale de tu dispositivo.

Para escanear un documento de 20 páginas, el reconocimiento óptico de caracteres (OCR) del navegador tarda aproximadamente entre 30 y 120 segundos. Un servicio en la nube podría tardar entre 2 y 5 segundos. La disyuntiva es entre privacidad y velocidad.

La arquitectura: del archivo a la salida

Esto es lo que sucede cuando, por ejemplo, comprimes un PDF en LuraPDF:

1. Selección de archivo: Arrastra un PDF a la zona de destino. La API de archivos del navegador lee el archivo y lo almacena en un ArrayBuffer (bytes sin procesar en la memoria del navegador). No se realiza ninguna carga.

2. Validación: Una comprobación rápida de que los bytes mágicos %PDF aparecen al inicio del ArrayBuffer.

3. Cargando: PDFDocument.load() de pdf-lib analiza la tabla de referencias cruzadas, lee el árbol de objetos y construye una representación en memoria del documento.

4. Enumeración de imágenes: La biblioteca recorre los flujos de contenido de la página para encontrar objetos XObject de imagen (imágenes incrustadas). Se extraen el ancho, la altura, el tipo de compresión y los datos en bytes de cada imagen.

5. Recodificación: Para cada imagen, los datos de píxeles sin procesar se dibujan en un elemento HTML Canvas y luego se reexportan con un factor de calidad JPEG más bajo usando canvas.toBlob('image/jpeg', quality) . El objeto de imagen original se reemplaza con la versión codificada más pequeña.

6. Serialización de documentos: El método save() de pdf-lib serializa el documento modificado de nuevo a bytes. Los flujos de objetos se comprimen con DEFLATE.

7. Descarga: Los bytes se envuelven en un objeto Blob, se crea una URL de objeto temporal ( URL.createObjectURL(blob) ) y un clic programático <a> activa el mecanismo de descarga del navegador.

Total de datos transmitidos a cualquier servidor externo: cero bytes.

Web Workers: Manteniendo la interfaz de usuario adaptable

El procesamiento de archivos PDF consume muchos recursos de la CPU. Si se ejecutara en el hilo principal de JavaScript, la pestaña del navegador se congelaría: no se podría desplazar, hacer clic ni ver las actualizaciones de progreso mientras se procesa el archivo.

LuraPDF ejecuta todos los cálculos complejos (OCR, análisis de archivos PDF grandes, recodificación de imágenes) en Web Workers: hilos JavaScript independientes que se ejecutan en segundo plano. El hilo principal gestiona la interfaz de usuario, muestra barras de progreso y se comunica con el worker mediante el paso de mensajes (postMessage / onmessage).

Cuando se ejecuta el OCR, se activa un evento de progreso después de procesar cada página. El proceso envía { page: 5, total: 20, confidence: 94 } al hilo principal, que actualiza la barra de progreso. La interfaz de usuario permanece interactiva en todo momento.

Gestión de memoria

La memoria del navegador es limitada. Un PDF de 200 MB cargado en memoria, procesado y guardado podría requerir entre 400 y 600 MB de RAM (bytes originales + datos intermedios de Canvas + bytes de salida). En sistemas con RAM limitada, esto puede generar problemas de memoria.

Estrategias utilizadas:

• Procesamiento de páginas en streaming: Para operaciones de varias páginas, las páginas se procesan y los elementos Canvas intermedios se descartan después de su uso.
• URL.revokeObjectURL(): Las URL de blobs temporales se revocan después de la descarga para permitir la recolección de basura.
• Terminación del trabajador: Los trabajadores web se terminan después de completar su tarea para recuperar la memoria que utilizaron.

Para archivos muy grandes (>100 MB), los navegadores modernos los manejan sin problemas en sistemas con 8 GB o más de RAM. Los sistemas más antiguos o con memoria limitada pueden tener dificultades con archivos de origen de más de 100 MB.

La arquitectura de privacidad

El modelo de seguridad se aplica mediante la política de mismo origen y la arquitectura de aislamiento del navegador:

• Sin solicitudes HTTP: No se permiten llamadas a API externas, telemetría ni análisis durante el procesamiento de documentos.
• Ejecución en entorno aislado: Los Web Workers no pueden realizar llamadas de red a orígenes externos.
• Sin almacenamiento persistente: Los archivos procesados ​​no se escriben en el almacenamiento del navegador (localStorage, IndexedDB o acceso al sistema de archivos).
• Memoria con ámbito de pestaña: Al cerrar la pestaña, todos los objetos ArrayBuffer y Blob asociados a ella se eliminan mediante el recolector de basura.

Esta arquitectura es verificable: abre la pestaña Red del navegador en las herramientas para desarrolladores mientras procesas un archivo. Verás que no se registra ninguna solicitud durante el procesamiento.

Bibliotecas de código abierto: inspeccionables, no cajas negras

Las tres bibliotecas principales —pdf-lib, pdfjs-dist y Tesseract.js— son de código abierto y cuentan con repositorios públicos en GitHub. Cualquiera puede inspeccionar sus implementaciones. El código de procesamiento de PDF que se ejecuta en LuraPDF no es una caja negra propietaria; es código público con usuarios reales, incidencias y contribuciones.

Esto es fundamental para generar confianza. Cuando un servicio en la nube afirma que "procesamos y eliminamos sus archivos", usted confía en su palabra. En cambio, cuando LuraPDF utiliza bibliotecas de código abierto en un entorno aislado del navegador, sin llamadas de red, puede verificar esta afirmación consultando la pestaña de red.

Ventajas y desventajas del procesamiento en la nube

El modelo basado en navegador tiene desventajas reales que conviene reconocer con honestidad:

Velocidad: Los servicios en la nube cuentan con clústeres de GPU e infraestructura dedicada. El OCR en el navegador para documentos grandes tarda entre 2 y 10 veces más que una solución equivalente en la nube. La compresión es rápida porque utiliza directamente la API de Canvas.

Límites de tamaño de archivo: La memoria del navegador es el factor limitante. Los archivos muy grandes (>300 MB) pueden alcanzar los límites de memoria en algunos sistemas. Los servicios en la nube no tienen esta limitación.

Potencia de procesamiento: WASM funciona al 40-80% de la velocidad nativa de C++. Los servicios en la nube ejecutan código nativo optimizado. Para la mayoría de los documentos, esta diferencia es imperceptible; para trabajos de OCR de más de 100 páginas, se nota.

Características: Algunas funciones avanzadas de PDF (verificación de conformidad PDF/X, gestión profesional del color, flujos de trabajo CMYK) requieren herramientas especializadas del servidor. El procesamiento basado en navegador gestiona el 95 % de los casos.

Para el procesamiento diario de documentos (compresión, fusión, firma, conversión, edición), el modelo basado en navegador es lo suficientemente rápido, privado por diseño y no requiere cuenta ni suscripción.

Preguntas frecuentes

¿LuraPDF recopila algún tipo de telemetría o datos de uso? LuraPDF utiliza Google Analytics para obtener estadísticas agregadas de visitas a las páginas. Las operaciones de procesamiento de documentos no generan eventos analíticos. El contenido de sus archivos nunca se transmite.

¿Puedo verificar que no se ha producido ninguna carga? Sí. Abra las Herramientas para desarrolladores (F12), haga clic en la pestaña Red y filtre por "XHR" o "Fetch". Procese un archivo. No se observarán solicitudes de red relacionadas con el documento durante el procesamiento.

¿Por qué la OCR tarda tanto en comparación con otros servicios? Tesseract.js, basado en navegador, se ejecuta en la CPU mediante WebAssembly. Los servicios de OCR en la nube se ejecutan en clústeres de GPU que procesan los caracteres a una velocidad mucho mayor. La desventaja es que el documento nunca sale del navegador.

¿Qué sucede si cierro la pestaña mientras se está procesando? El procesamiento se detiene inmediatamente. La memoria de la pestaña del navegador se libera. Su archivo original en el disco permanece sin cambios.

¿El código es de código abierto? Las bibliotecas de procesamiento principales (pdf-lib, pdfjs-dist, Tesseract.js) son de código abierto. El código de la interfaz de LuraPDF no es de código abierto actualmente, pero el proceso utiliza exclusivamente componentes de código abierto.

El cambio al procesamiento de documentos basado en el navegador no es una simple estrategia de marketing. Se trata de una decisión arquitectónica genuina con ventajas tangibles en cuanto a privacidad y confianza, aunque a costa de la velocidad en operaciones intensivas. Para los documentos que prefiera que no se almacenen en el servidor de otra persona, es la compensación adecuada.