Sube un archivo a un convertidor basado en servidor y ocurren tres cosas. Tu archivo viaja por la red a una dirección IP que no controlas. Un proceso en ese servidor lo decodifica. Luego, dependiendo de la política de retención del sitio, el archivo permanece en disco desde minutos hasta para siempre.
Haz lo mismo en una pestaña del navegador y el archivo nunca sale de la RAM de tu máquina. El decodificador se ejecuta dentro de un sandbox WebAssembly que el motor del navegador impone. La red nunca se toca.
Esto no es una diferencia de política. Es arquitectónica. Un convertidor basado en servidor puede prometer eliminar tus archivos; uno basado en navegador no puede filtrarlos porque nunca los recibe en primer lugar.
La arquitectura
Cuatro capas hacen posible la conversión del lado del cliente:
Capa 1: Acceso a archivos
Cuando sueltas un archivo en una pestaña del navegador, el DragEvent o <input type="file"> le da a JavaScript un objeto File. Un File no es el contenido del archivo. Es una referencia: un nombre, un tamaño, un tipo MIME y un método (file.arrayBuffer()) que lee bytes del disco a la memoria bajo demanda.
Hasta que se llama a ese método, cero bytes se han movido. El archivo permanece en tu sistema de archivos. El selector de archivos del navegador es un diálogo a nivel de sistema operativo; la página web solo ve el objeto File que el usuario seleccionó explícitamente.
Capa 2: Detección de formato
Los primeros bytes de cualquier archivo identifican su formato de manera fiable. Un JPEG comienza con FF D8 FF. Un PNG comienza con 89 50 4E 47. Un archivo HEIC contiene una caja ftyp con una marca heic o heif en el desplazamiento 8.
Leer la cabecera de un archivo (los primeros 32 bytes, típicamente) es suficiente para confirmar lo que realmente es, independientemente de la extensión. Esta comprobación se ejecuta antes de que cualquier decodificador toque los datos de píxeles. Si la cabecera no coincide, el archivo se rechaza inmediatamente. Sin CPU desperdiciada, sin mensajes de error confusos a mitad de una decodificación.
Capa 3: Decodificación
Los bytes brutos se convierten en píxeles a través de un decodificador. Qué decodificador depende del formato:
- JPEG, PNG, WebP, BMP: el navegador incluye decodificadores nativos para estos.
createImageBitmap()entrega los bytes comprimidos al códec de la plataforma (Windows Imaging Component en Windows, Core Graphics en macOS, Skia en Linux/ChromeOS) y devuelve datos de píxeles brutos. Esta ruta es rápida, acelerada por hardware donde el sistema operativo lo admite y no requiere código adicional. - HEIC: ningún navegador excepto Safari incluye un decodificador HEIC nativo. Nuestro convertidor incluye libheif, una biblioteca C, compilada a WebAssembly. El binario
.wasm(~1,2 MB comprimido) se descarga una vez y se almacena en caché. Decodifica archivos HEIF/HEIC a píxeles RGB brutos completamente dentro del sandbox WASM. - PDF: PDF.js (el renderizador de PDF de Mozilla) renderiza cada página en un lienzo a la resolución solicitada. Sin renderizado del lado del servidor. El PDF nunca sale del navegador.
Cada decodificador lee de la memoria y escribe en la memoria. Ninguno abre sockets. El sandbox WASM en particular no puede hacer solicitudes de red: el navegador no expone APIs de red a los módulos WebAssembly. Incluso si el código C llamara a socket(), el sandbox lo interceptaría.
Capa 4: Codificación
Los píxeles brutos van al contexto 2D de un elemento <canvas>. canvas.toBlob() o canvas.toDataURL() llama al codificador integrado del navegador para la salida JPG, PNG o WebP. El codificador es código nativo de la plataforma: la misma ruta de código que tu sistema operativo usa para guardar capturas de pantalla.
La salida es un Blob, un búfer de bytes en memoria. Se entrega a un enlace de descarga o se empaqueta en un archivo ZIP construido en JavaScript. En ningún momento un solo byte toca un socket de red.
Lo que el navegador impone
Las páginas web se ejecutan dentro de un sandbox que el navegador mantiene a nivel de motor. Esto no es un acuerdo de cortesía. Se impone mediante el aislamiento de procesos:
Proceso de renderizado: el motor de JavaScript, el DOM y el tiempo de ejecución de WASM viven en un proceso aislado sin acceso directo al sistema de archivos ni a la red. Se comunica con el mundo exterior a través de IPC al proceso del navegador.
Aislamiento de sitios: los navegadores modernos colocan cada origen en su propio proceso de renderizado. Tus archivos en file-convert-factory.org son invisibles para JavaScript que se ejecuta en cualquier otro dominio.
Sandbox WASM: los módulos WebAssembly ven un búfer de memoria lineal plano y nada más. Sin APIs de sistema de archivos, sin fetch a menos que se importe explícitamente desde JavaScript, sin acceso al DOM ni a otras APIs del navegador. Lo peor que podría hacer un módulo WASM comprometido es corromper su propia memoria y bloquear la pestaña.
Un convertidor basado en servidor se ejecuta como un proceso privilegiado en el sistema operativo del servidor. Puede leer y escribir en disco, abrir conexiones de red y generar procesos hijo. El modelo de seguridad depende de la competencia y las intenciones del operador del servidor. El sandbox del navegador depende solo de la corrección del motor del navegador, y los sandboxes de los navegadores están entre los límites de seguridad más rigurosamente auditados en el software.
Lo que los convertidores basados en servidor prometen (y no prometen)
Los convertidores basados en servidor no son inherentemente maliciosos. Muchos son gestionados por equipos bien intencionados. El problema es estructural:
- El paso de subida es una copia. Tu archivo ahora existe en dos lugares. Tú controlas una copia. Otra persona controla la otra.
- La eliminación es una promesa. «Eliminamos los archivos después de 24 horas» significa confiar en la línea de registro, el trabajo cron, el sistema de respaldo y cada empleado con acceso al servidor. Nada de esto es verificable desde fuera.
- Los metadatos viajan con el archivo. Los datos EXIF de tu foto (coordenadas GPS, número de serie de la cámara, marca de tiempo) son parte de los bytes del archivo. Si el archivo se sube, los metadatos se suben. Nuestra guía de privacidad EXIF cubre exactamente lo que contienen y cómo eliminarlos. En resumen: cada convertidor en este sitio elimina metadatos porque decodifica píxeles y los recodifica, descartando todo lo que no son datos de imagen.
- HTTPS protege la tubería, no el punto final. TLS cifra la subida en tránsito. No hace nada sobre lo que sucede con el archivo después de que llega.
La garantía de privacidad de un convertidor basado en navegador es más limitada pero más sólida. Dice: tus archivos no salen de tu dispositivo porque no hay ruta de código para que lo hagan. Esto es verificable. Abre la pestaña Red en DevTools mientras conviertes un archivo. Verás el binario WASM cargarse una vez y luego nada. Cero bytes subidos. Sin solicitudes a /api/convert. Sin tráfico WebSocket. La conversión ocurre completamente dentro del proceso de renderizado.
Verifícalo tú mismo
No necesitas creer la palabra de nadie. Abre Chrome DevTools (F12), cambia a la pestaña Red y convierte un archivo en cualquier página de herramienta. La única actividad de red que verás:
- El HTML, CSS y JavaScript de la página: cargados una vez en la primera visita.
- El binario WASM (para convertidores HEIC): cargado una vez, almacenado en caché después.
- Solicitudes de análisis (si no las has bloqueado).
Ningún dato de archivo sale del navegador. El Content-Length de cada solicitud se mide en kilobytes, no en megabytes. Esto es verificable independientemente por cualquiera que sepa abrir DevTools.
No se puede decir lo mismo de un servicio basado en servidor. Subes el archivo, obtienes un resultado y confías en que el servidor lo eliminó.
Herramientas relacionadas
Cada convertidor en este sitio sigue esta arquitectura. El pipeline (soltar, validar, decodificar, codificar, descargar) se ejecuta de manera idéntica en las 23 herramientas:
- HEIC a JPG · HEIC a PNG · HEIC a WebP
- JPG a PNG · JPG a WebP · JPG a ICO
- PNG a JPG · PNG a WebP · PNG a ICO
- WebP a JPG · WebP a PNG · WebP a ICO
- BMP a JPG · BMP a PNG · BMP a WebP · BMP a ICO
- PDF a JPG · PDF a PNG · PDF a WebP
- Imagen a texto (OCR): misma arquitectura del lado del cliente, ejecuta Tesseract en WASM
Para los detalles técnicos detrás del sandbox WASM, consulta nuestro explicador de WebAssembly. Para una mirada más profunda a los metadatos que contienen tus fotos, la guía de privacidad EXIF explica cómo leerlos y eliminarlos byte por byte.
