¿Son privadas las herramientas PDF de navegador?

Qué significa realmente “en el navegador”

Cuando eliges un archivo en una página web, el navegador no lo sube. Le entrega a la página un objeto File a través de la File API: un identificador de unos bytes que ya existen en tu disco. La página puede leer esos bytes en memoria y hacer con ellos lo que quiera. Enviarlos a un servidor es un acto aparte y explícito: la página tiene que construir una petición de red y transmitir los datos a propósito.

Un sitio de PDF convencional sube tu archivo, ejecuta un motor en un servidor y devuelve un resultado. Tu documento sale de tu máquina, aterriza en un disco en alguna parte y dependes de una política de conservación que no puedes inspeccionar. Una herramienta de navegador se salta todo eso, porque el trabajo ocurre en el motor JavaScript que ya se está ejecutando en tu propio ordenador.

Pero la File API solo hace posible el procesamiento local; no hace imposible la subida. Una página que lee tu archivo localmente y además lo envía a un servidor es HTML perfectamente corriente. Por eso el resto de este artículo va de comprobar, no de confiar.

Cómo funciona en iBuildPDF

Todas las herramientas del sitio siguen los mismos cuatro pasos.

1. Leer. El archivo que seleccionas se lee en un ArrayBuffer: un bloque de bytes en bruto en la memoria de la pestaña.
2. Analizar o renderizar. El trabajo estructural (unir, dividir, rotar, editar metadatos, estampar marcas de agua, escribir números de página) se hace con pdf-lib 1.17.1, que analiza el grafo de objetos del PDF y escribe un documento nuevo. Todo lo que necesita ver una página como píxeles (miniaturas de página, exportación de imágenes, rasterizado) usa Mozilla PDF.js 3.11.174 para dibujar la página en un lienzo.
3. Producir. El documento terminado se serializa a bytes y se envuelve en un Blob: sigue siendo solo memoria dentro de la pestaña.
4. Descargar. La página llama a URL.createObjectURL() sobre ese Blob, lo que crea una URL blob: que apunta a los datos en memoria, y lanza una descarga desde ahí. Una URL blob: no pasa nunca por la red; es una referencia a algo que la pestaña ya tiene.

Ambas bibliotecas se cargan desde una CDN pública en esas versiones fijadas. Eso es una petición de red y la verás, pero ocurre al cargarse la página, descarga JavaScript y no lleva nada tuyo.

Nada de esto requiere una cuenta. Las cuentas existen solo para comodidades como los favoritos y las herramientas recientes, e iniciar sesión no cambia nada sobre dónde se procesa tu archivo.

Cómo comprobarlo tú mismo

No te fíes de nuestra palabra. Dos comprobaciones lo zanjan, y ninguna requiere conocimientos técnicos más allá de seguir los pasos.

Comprobación uno: vigila la red

Abre cualquier herramienta: comprimir un PDF o unir PDF valen. Pulsa F12 (o Cmd+Opción+I en un Mac) para abrir las herramientas para desarrolladores y selecciona la pestaña Red. Marca Conservar registro para que no se borre nada y recarga la página.

Verás la carga inicial: el documento HTML, el CSS, el JavaScript propio del sitio y las peticiones a la CDN de pdf-lib y pdf.js. Ahora pulsa el botón de limpiar para vaciar la lista y solo entonces elige tu archivo y ejecuta la herramienta.

Lo que deberías ver cuando termine el proceso es nada, o prácticamente nada. No aparece ninguna petición cuyo tamaño se parezca al de tu documento. Si apareciera alguna, podrías pulsarla y leer su pestaña Carga útil para ver exactamente qué se envió. La descarga en sí no aparecerá como petición al servidor, porque procede de una URL blob:.

Una comprobación útil de sentido común: apunta el tamaño de tu archivo y luego ordena el panel de red por la columna Tamaño. Ahí sería imposible esconder una subida.

Comprobación dos: desconecta

Esta es la prueba más contundente, porque no depende de interpretar nada. Carga la página de la herramienta y espera a que termine de cargarse por completo. Después apaga tu Wi-Fi, o pon el desplegable de limitación del panel de red en Sin conexión.

Ahora usa la herramienta. Elige un archivo, procésalo, descarga el resultado. Funciona. Una herramienta que necesitara un servidor no podría haber producido ese archivo, porque no había ningún servidor al que llegar.

Lo único que tienes que hacer bien es el orden: las bibliotecas tienen que estar en la caché del navegador antes de quedarte sin conexión, ya que se descargan al cargar la página. Primero cargar, segundo desconectar, tercero procesar.

De qué no te protege esto

El procesamiento local es una propiedad real con límites reales. Cuatro de ellos importan.

• Es una propiedad de la implementación, no de los navegadores. Nada en la plataforma web impide que una página suba un archivo que ha leído. "Se ejecuta en el navegador" es una afirmación sobre lo que hace el JavaScript de un sitio concreto, y la única razón para creerla es que lo hayas comprobado, que es para lo que está la sección anterior.
• Las analíticas de uso no son el contenido de los archivos. El sitio puede registrar que se usó una herramienta. No registra el archivo, ni su nombre, ni su tamaño, ni nada derivado de él, porque esos datos no llegan siquiera a la capa de analítica de la página.
• Tu dispositivo es la frontera de confianza. Una extensión de navegador con permiso para leer el contenido de la página, o una máquina comprometida, están dentro de esa frontera, y ninguna página web puede hacer nada al respecto. Si un documento es lo bastante delicado como para preocuparte, el estado de la máquina en la que lo abres importa más que el sitio en el que lo abres.
• La memoria es el techo. Como todo ocurre en una pestaña del navegador, los documentos muy grandes están limitados por la RAM disponible y no por un límite de subida. Explicamos dónde cae esa línea en qué tamaño de PDF puede manejar un navegador.

Cuándo hace falta de verdad un servidor

Algunos trabajos no se pueden hacer honestamente en una pestaña. Convertir un PDF en un archivo editable de Word, Excel o PowerPoint implica reconstruir un modelo de documento —párrafos, estilos, tablas— a partir de un formato que solo registra dónde van las marcas sobre una página. Eso necesita motores de análisis de diseño que no existen como JavaScript de navegador. Con el reconocimiento óptico de caracteres pasa lo mismo. iBuildPDF no hace OCR en absoluto; no hay ninguna herramienta así en el sitio.

Si un archivo va a un servidor, su recorrido cambia de forma. Se transmite, se escribe en almacenamiento, lo lee un proceso de trabajo y se conserva hasta que algo lo borra. Cada etapa es un lugar donde una copia puede sobrevivir más de lo que esperas, y ninguna de ellas es visible para ti.

Los conversores PDF↔Word, PDF↔Excel y PDF↔PowerPoint de iBuildPDF figuran como "próximamente" y están desactivados. Es deliberado: un conversor que no puede ejecutarse localmente no se publica en silencio con una subida detrás. Cuando esas herramientas se activen, dependerán de un servidor, y la página lo dirá.

Todo lo demás —las 31 herramientas publicadas, incluidas la censura, la eliminación de metadatos y la extracción de texto— se ejecuta hoy de forma local. El detalle técnico completo está en la página de referencia sobre privacidad de archivos.