El reconocimiento óptico de caracteres puede ejecutarse por completo dentro de una pestaña del navegador. En este sitio, Imagen a texto carga el motor de reconocimiento Tesseract.js como WebAssembly, lee la imagen desde la memoria local y devuelve texto editable, así que la imagen nunca se transmite. PDF a texto va más allá y normalmente evita el motor de reconocimiento por completo.
La ruta de PDF es el diseño más interesante. La herramienta recorre el documento página a página y lee primero cualquier capa de texto existente. Un PDF digital, exportado desde un procesador de textos o una herramienta de diseño, produce texto exacto en aproximadamente un segundo y nunca descarga el motor de reconocimiento. Solo las páginas que prácticamente no tienen texto, es decir, escaneos y fotografías, se rasterizan al doble de tamaño y se pasan al OCR. Ese enfoque en dos etapas hace que la gran descarga solo se pague cuando de verdad se necesita, y las páginas escaneadas se procesan de una en una a unos segundos cada una.
La razón por la que esto importa no es abstracta. Los documentos escaneados son la categoría que la gente menos cómoda se siente entregando: formularios firmados, cartas médicas, facturas, documentación de identidad, cualquier cosa fotografiada sobre un escritorio. Un motor de reconocimiento que se ejecuta en local elimina la decisión por completo, porque no hay ninguna copia sobre la que razonar.
Imagen a texto
Extrae el texto de una foto, una captura de pantalla o un escaneo. Varias imágenes se procesan en orden, y el resultado aparece en un cuadro editable que puedes copiar o descargar.
Qué cambia cuando el reconocimiento se ejecuta en el navegador
Un servicio de OCR basado en servidor recibe tu archivo, ejecuta el reconocimiento en su propio hardware y devuelve el texto. Una herramienta basada en el navegador descarga el motor en lugar del documento, y el tráfico fluye en la dirección opuesta.
| Reconocimiento en la pestaña | Reconocimiento en un servidor | |
|---|---|---|
| Qué cruza la red | Archivos de motor e idioma, en | Tu documento, fuera |
| Copias en el disco de otra persona | Ninguno | Al menos la subida, normalmente también un archivo de resultado |
| Cuenta | No es necesario | A menudo necesario para lotes o archivos más grandes |
| Funciona sin conexión tras la primera carga | Sí | No |
| Velocidad | Unos segundos por página escaneada | Más rápido en lotes grandes |
| Verificable por ti | Sí, en el panel de red | No |
Un detalle técnico merece conocerse porque explica por qué esto es posible sin una configuración especial del servidor. El motor es de un solo hilo y no usa SharedArrayBuffer, así que la página no necesita las cabeceras de aislamiento entre orígenes que normalmente requiere WebAssembly multihilo. Por eso puede servirlo un alojamiento estático corriente.
El diseño en dos etapas de PDF a texto
La mayoría de los PDF que la gente llama escaneos no son escaneos en absoluto. Un documento exportado desde un procesador de textos, una hoja de cálculo o un generador de informes contiene caracteres reales, situados en la página pero almacenados como texto. Reconocer esos caracteres con OCR sería algo extraño, porque introduce errores en datos que ya eran exactos.
Primera etapa: leer la capa de texto
La herramienta abre el PDF con PDF.js y pide a cada página su contenido de texto, y luego reconstruye el orden de lectura a partir de los datos de posición para que las líneas y los párrafos salgan en una secuencia sensata. Esta etapa es rápida y sin pérdida: los caracteres son los que ya contiene el archivo, así que no hay nada que pueda salir mal. Una página se considera que tiene capa de texto cuando contiene al menos 20 caracteres que no son espacios, un umbral deliberadamente bajo para que una página con un pie de foto realmente corto también se lea directamente.
Segunda etapa: reconocer solo las páginas que lo necesitan
Las páginas que no superan esa prueba son las que realmente son imágenes, y siguen otra ruta. Cada una se rasteriza a un lienzo al doble del tamaño normal, se convierte a PNG y se entrega al motor de reconocimiento. Duplicar la escala de rasterizado importa más de lo que parece, porque los modelos de OCR trabajan sobre trazos y bordes, y una página rasterizada a resolución de pantalla pierde el detalle fino de la letra pequeña.
| Documento | Qué hace la herramienta | Descarga del motor |
|---|---|---|
| PDF digital, todas las páginas tienen texto | Lee la capa de texto de cada página | Ninguno |
| PDF escaneado, sin capa de texto | Rasteriza cada página a 2x y la reconoce | Una descarga y luego en caché |
| Documento mixto, anexo escaneado | Lee las páginas de texto directamente y reconoce el resto | Una descarga, usada para parte del archivo |
El resultado te indica qué camino siguió cada página. El resumen informa del número de páginas, cuántas vinieron de la capa de texto y cuántas se reconocieron, y el cuerpo se divide en bloques de página. Esa distinción es útil en la práctica: si un documento que esperabas que fuera digital informa de un montón de páginas reconocidas, probablemente se imprimió a imagen en algún punto del camino.
PDF a texto
Las páginas digitales se leen de la capa de texto en aproximadamente un segundo. El motor de reconocimiento solo se carga para las páginas que son realmente imágenes.
Qué descarga realmente el motor
Aquí no se descarga nada cuando se carga la página. El motor llega a petición, la primera vez que pulsas el botón, y merece la pena dar las cifras porque explican tanto la demora como el funcionamiento sin conexión posterior.
- El núcleo ocupa unos 3.7 MB. Esa es la compilación WebAssembly del modelo de reconocimiento, y es un único archivo autoalojado en lugar de varias variantes.
- Los datos del idioma inglés ocupan unos 2.8 MB y se sirve desde este sitio, así que el caso habitual no necesita ningún tercero. En conjunto, la primera ejecución en inglés descarga unos 6.5 MB y el navegador los guarda en caché.
- Los demás idiomas provienen de un CDN público de datos de Tesseract. El selector incluye doce idiomas en total; el inglés es local, y los otros once, desde el chino y el japonés hasta el ruso y el árabe, se descargan en el primer uso y el motor los guarda en caché en IndexedDB.
- Se mantiene un worker a la vez. Un worker mantiene el núcleo más los datos de idioma en memoria, así que cambiar de idioma termina el anterior en lugar de apilarlos.
- La compatibilidad con SIMD se comprueba antes de cargar nada. El cargador valida primero una pequeña muestra de WebAssembly, porque la compilación del motor requiere instrucciones vectoriales. Sin esa comprobación, un navegador antiguo fallaría con un error de compilación de bajo nivel en lugar de un mensaje legible.
Cómo obtener un resultado limpio
- Elige el idioma antes de empezar. Es el único ajuste que decide la precisión, y solo se aplica a las páginas que pasan por el reconocimiento. Un PDF digital lo ignora por completo.
- Envía el origen más nítido que tengas. La foto original supera a una captura de la vista previa, y un escaneo plano supera a una foto hecha con el móvil en ángulo. Si solo tienes una foto, un ligero recorte hasta el bloque de texto ayuda más que cualquier ajuste.
- Endereza e ilumina. Una página girada unos grados, o iluminada desde un lado con una sombra en el centro, cuesta más precisión que una resolución más baja.
- Ejecútalo y lee la salida. El cuadro de resultado es editable, así que corrige ahí los nombres y los números en lugar de exportar y arreglarlo después.
- Comprueba el porcentaje de confianza. Se informa como una media de todo el archivo. Un número bajo es una señal para volver a mirar el origen, no un veredicto sobre el texto.
Si una foto necesita retoques antes del reconocimiento, Recortador de imágenes y Compresor de imágenes ambos se ejecutan en local, así que toda la cadena desde la foto original hasta el texto puede quedarse en el dispositivo.
Dónde sigue fallando el OCR
Ser claro sobre esto es más útil que una afirmación de confianza, porque los modos de fallo son predecibles y se agrupan en torno a cómo se produjo el origen, no en torno al motor.
- Gráficos de diseño y fondos de color. El modelo de reconocimiento se entrenó con documentos, no con carteles. Probado contra el propio gráfico de portada azul oscuro de este sitio, que tiene letras grandes y estilizadas, el motor devolvió un solo guion. Cualquier imagen en la que el texto sea decorativo en lugar de tipográfico es una mala candidata.
- Escritura a mano. El texto impreso es el objetivo. Las notas manuscritas, las firmas y las entradas de formularios producen resultados poco fiables, y ninguna cantidad de resolución lo soluciona.
- Escaneos deficientes. Recibos térmicos desvanecidos, faxes, fotocopias de fotocopias, páginas torcidas en el escáner. La precisión baja con cada uno de esos casos, y la herramienta no tiene forma de avisarte de qué palabras son dudosas.
- Velocidad en páginas escaneadas. El reconocimiento tarda unos segundos por página, y el trabajo ocurre en tu propia CPU, así que la pestaña está ocupada mientras se ejecuta. Un documento escaneado largo es un trabajo lento, no instantáneo.
- Cobertura de idiomas. Solo los doce idiomas del selector. Cualquier otro no es compatible, y una página que mezcla dos alfabetos se lee con el único modelo que elegiste, lo que reduce la precisión en el segundo.
- El diseño no se conserva. La salida es texto plano con marcadores de página. Las columnas, las tablas y las barras laterales salen como un flujo lineal, así que un diseño complejo necesita volver a formatearse después.
- Los PDF protegidos con contraseña hay que desbloquearlos primero. El lector no puede abrir un archivo cifrado, y la herramienta lo dice en lugar de fallar en silencio.
Cuándo es mejor un servicio basado en servidor
El reconocimiento local es la opción predeterminada correcta para un puñado de documentos, y es la herramienta equivocada para algunos trabajos concretos. Trescientas facturas escaneadas, un archivo con mucha escritura a mano, un alfabeto fuera de la lista compatible o la necesidad de una salida estructurada que conserve la geometría de las tablas apuntan todos en la misma dirección, porque requieren un rendimiento o unos modelos que una versión para navegador no incorpora.
El hábito útil es separar los dos casos antes de empezar. Si el documento es sensible y el volumen es pequeño, la ruta del navegador lo cubre y el archivo nunca se mueve. Si el volumen es grande, lo correcto es un servicio aprobado en lugar de cien ejecuciones manuales, y la decisión sobre qué servicio usar es organizativa, no técnica. Esa división, y cómo se aplica a los equipos que gestionan documentación de personal, legal o clínica, es el tema de documentos sensibles y la nube.