Por qué el OCR debe correr en tu navegador

Piensa en las últimas cosas de las que necesitaste extraer texto. La captura de una conversación privada. La foto de un contrato. Una factura. Un formulario con tu dirección. Ahora piensa en lo que ha significado siempre «OCR gratis en línea»: sube ese archivo al servidor de un desconocido y confía en él.

El problema silencioso de las herramientas que suben tu archivo

Casi todas las webs de OCR funcionan igual: subes la imagen, su servidor ejecuta el reconocimiento y te devuelve el texto. Incluso cuando quien lo opera es honesto, el modelo tiene problemas estructurales:

• Tu archivo existe en hardware que no controlas, aunque sea brevemente, y «borramos los archivos después de procesarlos» es una promesa, no una propiedad que puedas verificar.
• Tránsito y registros. Los archivos pasan por balanceadores de carga, almacenamiento temporal y registros de peticiones. Cada uno es un sitio donde los datos pueden quedarse.
• Condiciones que no leíste. Algunos servicios gratuitos se reservan el derecho de usar lo que subes para «mejorar el servicio», lo que puede significar que tu documento acabe siendo material de entrenamiento.
• Las filtraciones ocurren, incluso en servicios bien gestionados. Un servidor que nunca recibe tu archivo no puede filtrarlo.

Nada de esto exige mala intención. Es simplemente lo que la arquitectura hace posible.

La alternativa: no enviar el archivo a ninguna parte

Los navegadores modernos pueden ejecutar redes neuronales de verdad. WebAssembly es lo bastante rápido, y los modelos de OCR lo bastante pequeños para descargarse una vez y lo bastante precisos para texto impreso. Eso invierte el modelo: en lugar de enviar tu archivo al código, el código viene a ti.

Esto es lo que ocurre cuando usas la herramienta para extraer texto de una imagen en este sitio:

1. Tu navegador descarga los modelos de OCR (unos 30 MB) y el runtime de WebAssembly desde este dominio, como cualquier otro recurso estático. Quedan en caché después de la primera visita. Un reconocedor específico para coreano (~13 MB) se carga solo si la primera pasada parece hangul.
2. El reconocimiento se ejecuta en tu máquina. El archivo no sale de la pestaña.
3. El resultado aparece en tu pantalla. Ninguna petición contiene tu imagen, tu texto ni el nombre de tu archivo.

La misma cadena se encarga de las capturas y de las páginas de PDF escaneadas. Los PDF digitales los analiza pdf.js en la pestaña: tampoco hay subida.

Verifícalo, no te fíes

Lo bueno del procesamiento local es que la afirmación se puede comprobar:

• Abre las herramientas de desarrollo del navegador, ve a la pestaña Red y extrae algo. Verás la descarga de los modelos (solo la primera vez) y nada más.
• O ponlo más difícil: carga la página, apaga el wifi y extrae. Funciona, porque ya no queda nada con lo que hablar.

Prueba a pedirle esa demostración a un servicio basado en subidas.

Las contrapartidas, con honestidad

El OCR local no es magia; mueve los costes de sitio:

• La primera carga es más pesada. Descargas el motor una vez (después queda en caché). Las herramientas basadas en subidas tienen una primera página más ligera, pero envían tus datos.
• El trabajo lo hace tu dispositivo. En un portátil moderno suele ser menos de un segundo por captura; una página de PDF escaneada tarda unos segundos. El hardware muy antiguo es más lento.
• La cobertura de idiomas es finita. El modelo por defecto lee texto impreso en español, inglés, alemán, francés, japonés y coreano, además de chino. La escritura a mano y los alfabetos fuera de ese conjunto siguen favoreciendo a un modelo grande en servidor.

Para capturas, documentos y fotos de texto impreso —el caso habitual— el modelo local es lo bastante preciso e instantáneo después de la primera carga. Y es la única arquitectura en la que «tus archivos nunca salen de tu dispositivo» es un hecho y no una política.