Tus archivos no se suben: cómo funciona el procesamiento local de PriviTools

Una herramienta web suele pedirte que subas un archivo antes de hacer algo con él. Para combinar un PDF, convertir una hoja de cálculo, extraer texto de una imagen o censurar un documento, el flujo habitual es: navegador → servidor → resultado. Eso puede ser práctico, pero también hace que el contenido salga de tu dispositivo.

PriviTools parte de una arquitectura distinta para las herramientas identificadas como locales: el archivo se abre, transforma y convierte en el navegador. PriviTools no recibe el documento ni el texto introducido para procesarlo en sus servidores.

Es una diferencia importante, pero merece explicarse sin frases absolutas. Procesamiento local no significa que una página web nunca haga solicitudes de red. Significa que la ruta que trata tu archivo no lo envía a un backend para procesarlo. Esta es la arquitectura, la evidencia que tenemos y los límites que debes conocer.

El recorrido de un archivo: del selector a la descarga

Cuando eliges un archivo o lo arrastras a una herramienta, el navegador lo entrega a la página como un objeto File. La aplicación sólo puede leer el contenido de los archivos que has seleccionado explícitamente; esa es una restricción del propio modelo web. La File API permite leer ese objeto dentro del navegador.

En una operación local típica, el recorrido es este:

Archivo elegido por la persona
        ↓
Memoria del navegador (File / ArrayBuffer)
        ↓
Lógica de la herramienta y, cuando corresponde, Web Worker
        ↓
Resultado en memoria (Blob)
        ↓
Descarga iniciada por el navegador

No hay un paso de «subir el archivo» entre la selección y el resultado. Por ejemplo, las operaciones de PDF delegadas reciben los datos como ArrayBuffer y las procesan con bibliotecas que se ejecutan en el cliente. El resultado se prepara como un Blob, que el navegador puede ofrecer para descarga mediante una URL local blob:; no es una URL de un archivo almacenado en PriviTools. MDN documenta este mecanismo de URLs de objeto.

Por qué usamos Web Workers

Algunos archivos exigen trabajo intensivo: analizar la estructura de un PDF, renderizar páginas, aplicar censuras, hacer OCR o generar una copia final. Si todo se ejecuta en el hilo que pinta la interfaz, la página puede dejar de responder, especialmente en documentos grandes o equipos con poca memoria.

Por eso algunas operaciones se realizan en Web Workers. Son contextos de JavaScript separados del hilo de la interfaz que se comunican por mensajes. En la ruta de censura automática, por ejemplo, el ArrayBuffer del documento y las zonas que la persona revisó se entregan al Worker; el Worker devuelve el resultado y el progreso por página. Sigue siendo trabajo dentro del navegador, no una llamada a un servidor de conversión.

Un ArrayBuffer puede transferirse al Worker, moviendo la propiedad de esos bytes entre los dos contextos sin que el archivo tenga que viajar por Internet. La transferencia no es una garantía de rendimiento idéntico en todos los equipos, pero evita copias innecesarias en los casos que la soportan. Los objetos transferibles y sus límites están documentados por MDN.

La ventaja práctica no es sólo velocidad

No subir el documento cambia qué actores pueden intervenir en la operación. Un servicio en la nube puede necesitar guardar temporalmente el archivo, registrar un trabajo, aplicar controles de acceso y borrar una copia después. PriviTools no necesita esa cadena para las herramientas locales: el documento no entra en su infraestructura de procesamiento.

Esto reduce la exposición del contenido frente a esa infraestructura, pero no convierte cualquier archivo en seguro por sí mismo. Si una persona comparte el resultado por correo, lo sube a otra plataforma, usa un dispositivo comprometido o trabaja con una extensión maliciosa, esos son riesgos distintos que una herramienta local no puede eliminar.

La propuesta de privacidad, por tanto, es concreta: no añadir un servidor de PriviTools al recorrido de tu archivo. No es una promesa de anonimato absoluto, cumplimiento automático de RGPD o seguridad frente a todos los riesgos del dispositivo.

Qué verificamos, en vez de pedir que nos creas

La afirmación se prueba con flujos automatizados del proyecto. Las pruebas generan PDFs con datos canario —marcadores sintéticos diseñados para detectar una fuga— y observan las solicitudes que hace el navegador durante la carga, el análisis y la descarga.

La prueba falla si ocurre cualquiera de estas situaciones:

• un marcador aparece en una URL o en el cuerpo de una solicitud;
• un tercero recibe un cuerpo de petición grande;
• aparece un origen de red que no se haya aprobado explícitamente;
• el resultado de censura todavía revela el marcador en bytes, texto extraíble o metadatos.

Los flujos de censura automática y carga de PDF están cubiertos de este modo. Además, un barrido de páginas de herramientas vigila que no aparezcan orígenes nuevos sin revisión. No es una certificación universal de las 42 herramientas, todos los navegadores ni cualquier futura versión: es evidencia reproducible de los casos automatizados hoy. Cada cambio en dependencias, Workers o política de red exige volver a ejecutar las pruebas.

Lo que sí puede comunicarse con la red

Ocultar esta parte sería peor que explicar la arquitectura. Para mostrar una herramienta, el navegador descarga HTML, JavaScript, estilos y otros recursos del sitio. El proveedor de alojamiento también puede registrar datos técnicos ordinarios de conexión, como sucede con cualquier web.

Existen además acciones separadas de la herramienta: si decides enviar una sugerencia desde el formulario, ese mensaje se transmite al proveedor del formulario. No adjunta el archivo que estás procesando. Algunas funciones avanzadas también pueden descargar una biblioteca o un modelo antes de trabajar localmente; descargar ese componente no equivale a enviarle tu documento al proveedor.

La distinción que importa es sencilla:

Acción	¿Se transmite el contenido del archivo a PriviTools para procesarlo?
Abrir una herramienta local	No
Elegir, arrastrar o procesar el archivo	No
Descargar el resultado creado localmente	No
Enviar voluntariamente un mensaje de sugerencia	Se transmite el mensaje, no el archivo de la herramienta

La política de privacidad detalla estas separaciones y el almacenamiento local que algunas funciones usan para continuar el trabajo en el mismo perfil del navegador.

Qué debes comprobar antes de confiar en cualquier herramienta online

Una afirmación como «privado» no basta, aunque la haga PriviTools. Cuando un archivo sea sensible, conviene hacer estas comprobaciones:

1. Lee si la herramienta declara dónde procesa el archivo y si explica excepciones.
2. Revisa las solicitudes en las herramientas de desarrollo del navegador o en una auditoría de red independiente.
3. Comprueba si el resultado se descarga directamente o si recibes un enlace temporal a un servidor.
4. Revisa la copia final, especialmente después de censurar, convertir u OCR.
5. Conserva el original protegido y usa una revisión independiente si el documento es de alto riesgo.

Para la censura de un PDF, la comprobación final es indispensable: un rectángulo negro puede ocultar texto sin eliminarlo. Consulta nuestra guía sobre cómo censurar un PDF de forma irreversible y verifica siempre el archivo descargado.

Privacidad que se puede inspeccionar

La fortaleza de PriviTools no es decir «confía en nosotros». Es mantener el procesamiento de las herramientas locales donde el archivo ya está —tu navegador— y convertir esa decisión en algo que puede revisarse: código de cliente, límites explícitos, pruebas de red y resultados que se descargan desde el propio dispositivo.

El navegador no elimina todas las obligaciones de seguridad. Sí permite evitar una decisión que muchas herramientas online tratan como inevitable: entregar tu documento a un backend sólo para transformarlo.