Cómo funciona la conversión de archivos en el navegador

La mayoría de los conversores en línea suben tu archivo a un servidor. El nuestro no puede: todas las herramientas de este sitio hacen la conversión dentro de tu navegador, con JavaScript y WebAssembly. Esta página explica exactamente qué significa eso, cómo comprobarlo por tu cuenta y, tan importante como eso, qué hace imposible.

Por qué «sin subida» es una diferencia arquitectónica real

Un conversor basado en servidor es un cliente ligero: tu navegador envía el archivo, el servidor hace el trabajo y el resultado vuelve. Ese diseño tiene ventajas (el servidor puede ejecutar cualquier biblioteca, por grande que sea) y un coste estructural: el archivo tiene que existir en una infraestructura que no controlas, al menos durante un tiempo. Las políticas de retención, los registros y las copias de seguridad quedan fuera de tu vista.

Este sitio está construido al revés. No hay ningún endpoint de subida. La página carga una biblioteca de JavaScript que decodifica el archivo en memoria, lo transforma y devuelve el resultado como una descarga local. Si se cortara la red después de cargar la página, la herramienta seguiría funcionando.

El proceso, paso a paso

1. Leer. El archivo se lee con las API del navegador FileReader / File.arrayBuffer(). Se convierte en bytes en la memoria de la página, nunca en una petición.
2. Decodificar. Esos bytes los decodifican los códecs de imagen propios del navegador (mediante <img> o createImageBitmap) o una biblioteca WebAssembly incluida para los formatos que el navegador no admite de forma nativa, como libheif para HEIC o pdf.js para páginas PDF.
3. Transformar. Los datos decodificados se dibujan en un <canvas> o se manipulan en memoria: redimensionar, recortar, girar, recolorear, recodificar.
4. Codificar. El canvas se vuelve a escribir en un formato binario con canvas.toBlob(), o se reconstruye un documento con una biblioteca de JavaScript puro como pdf-lib.
5. Entregar. El resultado se convierte en un Blob y en una URL de objeto, que la página activa como descarga. No se transmite nada.

Cómo comprobarlo tú mismo

No te fíes de lo que dice esta página. Abre las herramientas de desarrollo de tu navegador, ve al panel Red y convierte un archivo. Después mira qué ha pasado:

• Verás peticiones de la página, la hoja de estilos, las bibliotecas de JavaScript y la etiqueta de analítica, todas por URL.
• No verás ninguna petición cuyo cuerpo sea tu archivo. No hay ningún POST con unos cuantos megabytes de carga útil.
• En ese mismo panel, marca «Sin conexión» una vez cargada la página y vuelve a convertir. Sigue funcionando, algo que no podría hacer si hubiera un servidor de por medio.

Si quieres ir más lejos, observa la pestaña Memoria o Rendimiento mientras conviertes un PDF grande y verás que la asignación ocurre en el propio proceso de la página.

Lo que un navegador hace bien

• Decodificar y codificar imágenes. JPEG, PNG, WebP, GIF y AVIF se decodifican de forma nativa, y el canvas puede codificar la mayoría de vuelta.
• Transformaciones de píxeles. Redimensionar, recortar, girar, componer, ajustar el color: todo asistido por hardware a través de la API de canvas.
• Renderizado de páginas PDF. pdf.js es un renderizador de PDF completo escrito en JavaScript, así que una página puede convertirse en un canvas a cualquier resolución.
• Ensamblaje de documentos. pdf-lib puede crear y modificar estructuras PDF (unir, dividir, reordenar, añadir superposiciones) sin renderizar nada.
• Procesamiento de texto. JSON, CSV, Markdown, Base64 y formatos similares no cuestan nada en JavaScript.

Lo que un navegador no puede hacer

Ser honestos con esto importa más que enumerar capacidades, porque estos límites son la razón de que algunas conversiones se comporten aquí de forma distinta que en una herramienta basada en servidor.

• Recomprimir en su sitio las imágenes incrustadas de un PDF. Un optimizador de servidor puede decodificar cada imagen de un PDF, recodificarla de forma más eficiente y reconstruir el archivo con la capa de texto intacta. En un navegador esto no es práctico, y por eso nuestra compresión de PDF ofrece dos modos: reempaquetar el archivo (el texto se mantiene, el ahorro es modesto) o rasterizar las páginas (ahorro grande, el texto se convierte en imagen).
• Codificar AVIF en todos los navegadores. Crear un AVIF requiere el codificador del navegador, que hoy solo existe en los navegadores basados en Chromium. En Firefox y Safari un conversor debe decirlo en lugar de producir otra cosa en silencio.
• Decodificar TIFF, o HEIC sin ayuda. Los navegadores no incluyen estos códecs, así que hay que descargar un decodificador WebAssembly: unos 600 KB para el de HEIC, descargado una vez y luego en caché.
• Codificar GIF. Los navegadores decodifican GIF pero no lo codifican, así que una salida GIF requiere un codificador en JavaScript.
• OCR sin modelo. Leer texto de un escaneo necesita un modelo de reconocimiento entrenado de varios megabytes; es otro tipo de función, no una conversión de formato.
• Manejar archivos de cualquier tamaño. Todo vive en la memoria de la página, así que el techo práctico es la RAM de tu dispositivo y no una cuota de servidor. Unos cientos de megabytes funcionan en una máquina moderna; varios gigabytes, no.

Por qué publicamos los límites

Una herramienta que afirma no tener límites normalmente esconde algo. Publicarlos te permite decidir si una conversión concreta merece la pena aquí, y hace que las cifras de las páginas de herramientas (la resolución, la calidad, el tamaño del archivo) se puedan contrastar con lo que la implementación hace de verdad.

Si escribes sobre herramientas que funcionan en el navegador y necesitas citar algo, esta página está pensada exactamente para eso. No hace falta permiso.

← ← Volver a las herramientas