Transforma código HTML en texto limpio y legible. Este ligero convertidor de HTML a texto procesa el marcado con el analizador HTML del propio navegador, elimina las etiquetas y devuelve el texto que contienen.
Qué hace la herramienta:
- Elimina cada etiqueta HTML y elimina los bloques
<script>,<iframe>,<object>y<embed>junto con su contenido. - Decodifica entidades como
&, y–en caracteres reales - Mantiene los saltos de línea de tu fuente, por lo que HTML escrito un elemento por línea permanece legible
- Acepta hasta 500 KB de margen de beneficio por conversión
- Se ejecuta completamente en tu navegador: no se carga nada, no se almacena nada
Cómo utilizar este convertidor de HTML a texto
- Pega tu HTML en el cuadro superior
- Haz clic en Convertir a texto
- Revisa el texto sin formato en el cuadro inferior.
- Haz clic en Copiar resultado para capturarlo, o Borrar para empezar de nuevo
Un rápido antes y después:
<h2>Order & shipping</h2>
<p>Ships in <strong>2–3 days</strong>.</p>
<ul>
<li>Free returns</li>
<li>Tracked delivery</li>
</ul>Order & shipping
Ships in 2–3 days.
Free returns
Tracked deliveryDos cosas que debe saber antes de pegar: los bloques HTML minimizados sin saltos de línea aparecen como una línea larga, y los bloques <style> no se eliminan, así que elimínelos primero si tu fuente lleva CSS en línea. Para cualquier cosa que no sea un solo documento, la sección de biblioteca más abajo es la mejor ruta.
Trabajos típicos: crear una alternativa de texto sin formato para un correo electrónico HTML, extraer una copia legible de páginas eliminadas, limpiar el contenido antes de una migración de CMS o introducir texto limpio en un proceso de PNL.
¿Qué es un convertidor de HTML a texto?
Un conversor de HTML a texto es una utilidad de software que elimina marcas, etiquetas y entidades codificadas de un documento manteniendo el texto legible debajo.
Funciona en el código fuente sin formato de una página o archivo, no en una captura de pantalla renderizada.
El resultado es texto sin formato. Sin formato, sin estilo, nada que un navegador necesitaría para dibujar un diseño.
La gente confunde esto con algunas otras cosas que no lo son.
- No es un renderizador. Un renderizador dibuja la página visualmente, esto descarta la capa visual por completo.
- No es una herramienta de captura de pantalla. No hay imagen, sólo personajes.
- No es un motor OCR. OCR lee píxeles, un conversor de HTML a texto lee marcas que ya contienen texto
El valor aparece en cualquier lugar donde el marcado sin formato deba convertirse en algo que un ser humano, un script o una canalización de aprendizaje automático pueda realmente usar.
Mailchimp genera automáticamente una versión en texto plano de cada HTML campaña de correo electrónico enviada a través de su plataforma. Existe principalmente para bandejas de entrada y clientes de correo que rechazan el formato enriquecido.
Ese caso de uso único (contenido alternativo del correo electrónico) es uno de docenas en los que se aplica el mismo proceso subyacente.
HTML a texto frente a HTML a Markdown
La salida de texto sin formato conserva solo las palabras. La salida Markdown mantiene las palabras más una versión ligera de la estructura, encabezados, negritas, enlaces y listas representados como símbolos en lugar de etiquetas.
Los dos objetivos resuelven problemas diferentes y elegir el equivocado causa dolores de cabeza más adelante.
Qué texto sin formato mantiene:
- Oraciones, párrafos y redacción sin formato.
- Nada más. Sin énfasis, sin niveles de título, sin sintaxis de enlace
Qué guarda Markdown:
- Todo lo que se conserva en texto plano
- Niveles de encabezado marcados con símbolos de almohadilla
- Marcadores en negrita y cursiva, viñetas de lista y sintaxis de enlaces
Pandoc (EN), el conversor de documentos de código abierto ampliamente utilizado, los trata como dos formatos de salida separados en lugar de variaciones de lo mismo.
Elige texto sin formato para índices de búsqueda, filtros de spam y canales de PNL que solo se preocupan por las palabras.
Elige Markdown para sistemas de documentación, generadores de sitios estáticos o cualquier lugar donde la estructura necesite sobrevivir al viaje.
Si necesita la dirección inversa, volviendo a convertir Markdown en HTML, una herramienta dedicada de Markdown a HTML maneja esa conversión.
Cómo funciona un convertidor de HTML a texto
Cada convertidor ejecuta la misma secuencia aproximada: cargar el marcado, quitar las etiquetas, decodificar las entidades, limpiar los espacios en blanco, devolver el texto.
Los detalles de cada paso varían mucho entre herramientas, y esos detalles deciden si el resultado es utilizable o confuso.
Extracción basada en analizador versus extracción basada en expresiones regulares
La extracción basada en expresiones regulares compara patrones de etiquetas con expresiones regulares y elimina todo lo que parezca una etiqueta.
Es rápido y simple, y se rompe con etiquetas anidadas o con formato incorrecto HTML con más frecuencia de lo que la gente espera.
Extracción basada en analizador: primero crea un árbol de modelo de objetos de documento real a partir del marcado y luego recorre ese árbol para extraer nodos de texto.
Extracción basada en expresiones regulares: omite el árbol por completo y trata todo el documento como una cadena con la que comparar patrones.
Readability.js (EN) de Mozilla, la biblioteca detrás de Reader View de Firefox, utiliza análisis DOM completo en lugar de coincidencia de expresiones regulares. Esa es parte de la razón por la que sobrevive a páginas desordenadas del mundo real en las que se ahogan las herramientas de expresiones regulares.
Decodificación de entidades
Conversiones de entidades comunes:
&se convierte en un signo comercial se convierte en un espacio simple<y>se convierten en los caracteres menor que y mayor que
Un convertidor tiene que invertir esta codificación, o la salida estará llena de códigos de entidad literales en lugar de los caracteres que representan.
Decodificar la misma entidad dos veces corrompe el texto en lugar de arreglarlo, lo cual es un error más común de lo que la mayoría de la gente supone.
Normalización de espacios en blanco
Raw HTML está lleno de espacios en blanco que no significan nada para un navegador y parecería un caos en texto sin formato.
La sangría, las tabulaciones y los saltos de línea en el código fuente se contraen porque el navegador ya ignora la mayoría de ellos al renderizar.
- Múltiples espacios consecutivos colapsan en uno
- Los saltos de línea dentro de una etiqueta de un solo párrafo se eliminan o reemplazan con un espacio
- Los saltos entre elementos a nivel de bloque (párrafos, divs, elementos de lista) se conservan como saltos de línea reales
Formatos de entrada y codificaciones de caracteres admitidos
Un convertidor tiene que identificar correctamente dos cosas antes de tocar el contenido: la versión de marcado y la codificación de caracteres.
Si se equivoca cualquiera de los dos, el resultado se convertirá en símbolos confusos en lugar de texto legible.
Adopción de codificación y marcado:
- UTF-8 codifica 98.5% de todos los sitios web rastreados por W3Techs (EN), lo que lo convierte en la suposición predeterminada para cualquier convertidor moderno.
- HTML5 es el lenguaje de marcado detrás del 95.7% de los sitios web actualmente en línea, según la misma encuesta (EN)
- ISO-8859-1, la siguiente codificación más común después de UTF-8, está a la zaga de sólo el 1.1% de los sitios. Esa brecha es lo suficientemente amplia como para que la mayoría de las herramientas la traten como un recurso alternativo en lugar de un objetivo.
Los documentos XHTML siguen las reglas de sintaxis más estrictas de XML (EN), lo que significa que cada etiqueta debe cerrarse correctamente o el análisis fallará por completo.
Las secciones CDATA se encuentran dentro del marcado específicamente para contener contenido que un analizador no debe tocar. Los bloques de script y los datos en línea son ejemplos comunes, y se supone que un convertidor los omite en lugar de extraer su contenido sin procesar como texto legible.
HTML mal formado (etiquetas no cerradas, anidamiento no coincidente) es la razón más común por la que un convertidor produce resultados rotos o incompletos. Vale la pena realizar pruebas antes de confiar en una herramienta con contenido de producción.
Cómo se manejan los enlaces, tablas y listas en texto sin formato
Los elementos estructurales HTML no sobreviven al viaje al texto plano de la misma manera.
Cada uno se aplana según las reglas que define el convertidor, y esas reglas difieren de una herramienta a otra.
Tres resultados para un hipervínculo:
- Eliminado por completo, solo queda el texto del enlace.
- En línea, la URL aparece justo al lado del texto entre paréntesis o corchetes.
- Convertido a nota al pie, con una referencia numerada en el cuerpo y la URL completa enumerada por separado.
Las tablas pierden su cuadrícula visual en el momento en que se convierten en texto sin formato.
Las filas normalmente se convierten en líneas y las columnas dentro de una fila se separan mediante espacios o tabulaciones. Esto funciona para tablas estrechas y se vuelve ilegible rápidamente para las anchas.
Si luego necesita las filas extraídas en un archivo estructurado, ejecute esa misma tabla a través de una tabla dedicada al convertidor CSV (EN). Mantiene las filas y columnas intactas en lugar de colapsarlas en texto suelto.
Las listas funcionan mejor que las tablas.
- Los elementos de la lista desordenados generalmente mantienen un guión o un asterisco en lugar de la viñeta.
- Los elementos de la lista ordenados mantienen su numeración
- Las listas anidadas mantienen una sangría relativa para que la jerarquía siga siendo visible
Elegir un método de conversión: herramienta en línea, biblioteca o script
Existen tres caminos prácticos para ejecutar una conversión de HTML a texto, y cada uno se adapta a un volumen de trabajo diferente.
Hacer coincidir el método con el trabajo es más importante que elegir el "mejor" en abstracto.
| Método | Esfuerzo de configuración | Capacidad de lotes | Mejor para |
|---|---|---|---|
| herramienta en línea | Ninguno, funciona en un navegador | Un archivo a la vez | Conversiones rápidas y ocasionales |
| Biblioteca de códigos | Instalar un paquete | Miles de archivos en bucle | Aplicaciones y herramientas internas |
| Script de línea de comando | Instalar más un archivo de script | Ejecuciones programadas y desatendidas | Flujos de procesamiento automatizados |
Una herramienta en línea no le pide nada a la persona que la usa, pega el marcado, recupere el texto y listo.
Se desmorona en el momento en que el trabajo implica más de un puñado de documentos.
Las bibliotecas de códigos se insertan directamente en el código backend (EN), lo que significa que una aplicación puede procesar por lotes miles de páginas durante la noche sin que una persona haga clic en nada.
Algunos servicios también exponen la conversión a través de una API (EN) invocable, que se adapta a los equipos que prefieren enviar una solicitud que administrar una dependencia.
Los scripts de línea de comandos se encuentran entre los dos, son lo suficientemente programables para un trabajo cron y lo suficientemente simples como para ejecutarlos manualmente cuando sea necesario.
Las mejores bibliotecas de HTML a texto por lenguaje
Cada lenguaje de programación importante tiene al menos una opción madura para esto, y la elección correcta generalmente depende de qué más depende el proyecto.
Bibliotecas de Python
- BeautifulSoup (EN), combinado con un analizador como lxml o html.parser, para extracción de propósito general con mucho control sobre la salida
- html.parser, integrado en la biblioteca estándar de Python, para trabajos livianos que no deberían agregar una dependencia
- html2text (EN), para resultados que se leen como Markdown en lugar de texto sin formato
from bs4 import BeautifulSoup
soup = BeautifulSoup(html, "html.parser")
for tag in soup(["script", "style"]):
tag.decompose()
text = soup.get_text(separator="\n", strip=True)BeautifulSoup4 registró más de 400 millones de descargas en los últimos 30 días en PyPI, según pepy.tech (EN). Eso dice algo sobre la frecuencia con la que los desarrolladores de Python lo utilizan de forma predeterminada.
html2text obtuvo 14.1 millones de descargas en un solo mes por sí solo, según PyPI Stats (EN). Un número menor, pero aún evidencia de un uso constante y dedicado.
Los dos rara vez compiten directamente. BeautifulSoup es el analizador general, html2text es el especialista en salidas con sabor Markdown.
JavaScript y bibliotecas Node.js
El paquete html-to-text (EN) npm obtiene aproximadamente 11 millones de descargas por semana según el registro npm, lo que lo convierte en la opción predeterminada en la mayoría de los proyectos Node.js que lo necesitan.
Se ejecuta en el lado del servidor, escrito para entornos JavaScript (EN) en lugar del navegador, y no depende de una implementación DOM real para funcionar.
import { convert } from "html-to-text";
const text = convert(html, {
wordwrap: false,
selectors: [{ selector: "a", options: { ignoreHref: true } }],
});- Maneja tablas, listas y enlaces con reglas de salida configurables.
- Funciona bien dentro de canales de correo electrónico basados en nodos que generan respaldos de texto sin formato
- Se envía con valores predeterminados razonables, por lo que la mayoría de los proyectos necesitan poca o ninguna configuración
Bibliotecas Java y Ruby
Tanto Java como Ruby se apoyan en una única biblioteca dominante en lugar de dividir la atención entre varias opciones.
jsoup (EN) (Java):
- Ventajas: selectores de estilo CSS familiares para cualquiera que haya escrito código de interfaz, mantenimiento activo, tolerante a HTML mal formado
- Contras: una dependencia más para proyectos que aún no tocan HTML en ningún otro lugar
Nokogiri (EN) (Ruby):
- Ventajas: rápido, basado en libxml2, maneja documentos HTML y XML igualmente bien
- Desventajas: depende de extensiones nativas, lo que en ocasiones complica la implementación en hosts restrictivos
Ninguna biblioteca está cerca de su idioma. La mayoría de los proyectos Java y Ruby utilizan uno de estos dos por defecto sin mucho debate.
Dónde se utiliza la conversión de HTML a texto
El mismo proceso subyacente aparece en cuatro rincones muy diferentes del software: correo electrónico, búsqueda y scraping, accesibilidad y aprendizaje automático.
Cada uno le pide al convertidor que resuelva un problema ligeramente diferente.
Dónde se ejecuta realmente la conversión:
- Sistemas de correo electrónico que generan un texto sin formato junto a la versión HTML
- Canalizaciones de raspado web que extraen contenido legible de las páginas rastreadas
- Lectores de pantalla y otras herramientas de asistencia que consumen el texto simplificado.
- Pasos de preprocesamiento de PNL que introducen texto limpio en un modelo
La Common Crawl Foundation (EN), una organización sin fines de lucro que archiva la web pública, extrae texto sin formato de cada página que rastrea en archivos WET separados creados específicamente para uso de aprendizaje automático. El raw HTML vive aparte, en sus archivos WARC.
Una sola instantánea mensual de ese proyecto cubre más de 2 mil millones de páginas. Eso da una idea de la escala de la frecuencia con la que esta conversión se ejecuta detrás de escena en lugar de frente al usuario.
En cuanto a la accesibilidad, NVDA es ahora el lector de pantalla más utilizado en general, utilizado regularmente por 65.6% de los encuestados a Encuesta de usuarios de lectores de pantalla WebAIM #10 (EN).
Cada uno de esos usuarios depende de un software que lee el contenido en un orden lineal basado en texto. Eso es exactamente lo que produce un conversor de HTML a texto una vez que se eliminan las etiquetas y el diseño.
La mayoría de los recursos de accesibilidad web (EN) ofrecen orientación más profunda sobre cómo estructurar páginas para esa audiencia. Tanto el orden del texto como el marcado semántico afectan la capacidad de un lector de pantalla para seguir una página.
El correo electrónico añade su propio toque. Apple Mail y Gmail juntos representan cerca del 90% de todas las aperturas de correo electrónico rastreadas por Litmus (EN). Una alternativa de texto sin formato generalmente tiene que representarse correctamente en solo dos entornos en lugar de docenas.
Cuando no se aplica la conversión de HTML a texto
La conversión falla o simplemente no tiene sentido en algunas situaciones específicas.
Conocerlos de antemano ahorra tiempo al depurar resultados que nunca iban a funcionar.
Donde se estropea:
- Contenido que solo existe después de que se ejecuta JavaScript, ya que la fuente sin formato HTML nunca lo contiene
- Diseños donde la posición y la alineación tienen significado, siendo los estados financieros y los formularios el ejemplo más claro.
- Flujos de trabajo que necesitan conservar el marcado original para su posterior reprocesamiento
- Documentos tan mal formados que un analizador no puede construir un árbol utilizable en absoluto
El primer elemento de esa lista es el más importante en la práctica.
JavaScript ahora se ejecuta en el 98.9% de todos los sitios web, según W3Techs (EN). Una proporción cada vez mayor de esos sitios muestra su contenido real del lado del cliente en lugar de enviarlo en la respuesta inicial HTML.
Las aplicaciones de una sola página creadas con marcos como React o Vue a menudo ofrecen poco más que un shell vacío y una etiqueta de script en su código fuente sin formato. Un convertidor apuntado a esa fuente no devuelve casi nada útil.
La solución habitual es buscar primero la página a través de un navegador sin cabeza, para que JavaScript tenga la posibilidad de ejecutarse. En ese momento, la tarea pasó de la simple conversión a la representación de página completa.
El diseño visual es el segundo punto de falla recurrente.
Un convertidor aplana una factura de dos columnas en un solo flujo de líneas. La relación entre una línea de pedido y su precio puede perderse en el momento en que las columnas colapsan.
Cómo convertir HTML a texto paso a paso
El proceso es el mismo independientemente del método anterior que elija, solo cambian las herramientas.
- Confirma que la fuente sea válida HTML (EN) y verifique su codificación de caracteres declarada antes de tocar el contenido.
- Elige un método que coincida con el volumen: una herramienta en línea para un archivo, una biblioteca para un script, un trabajo programado para lotes recurrentes
- Ejecute la conversión y observe cómo maneja las entidades, ya que aquí es donde aparece primero la salida corrupta.
- Verifica el resultado de la eliminación de etiquetas con el original, confirmando que los enlaces, tablas y listas se resolvieron de la forma esperada.
- Validar el texto final con el documento fuente, buscando específicamente contenido que desapareció silenciosamente.
El tercer paso merece especial atención.
Una forma rápida de detectar problemas de entidades de manera temprana es buscar en la salida un signo literal seguido de letras. Ese patrón generalmente significa que algo no se pudo decodificar.
Los equipos que ejecutan esta conversión según un cronograma a menudo la conectan a la automatización existente. GitHub Actions es un lugar común para activar un trabajo por lotes de la noche a la mañana en lugar de ejecutarlo manualmente.
Saltarse el paso cinco es el atajo más común que vuelve en contra de la gente más adelante.
Errores comunes durante la conversión de HTML a texto
La mayoría de los problemas de conversión se deben a un pequeño puñado de errores recurrentes.
Ninguno de ellos es exótico. Simplemente se pasan por alto porque el resultado se ve bien de un vistazo.
| error | causa | Arreglar |
|---|---|---|
| Entidades doblemente decodificadas | Ejecutar la decodificación de entidades dos veces en una tubería | Decodifica una vez, registra el paso para que no se repita en el futuro |
| Caracteres ilegibles | Ignorando la codificación declarada | Detectar o confirmar la codificación antes de que comience el análisis |
| Fragmentos de código sobrantes | Eliminación de script incompleto o etiqueta de estilo | Quite los bloques de escritura y estilo antes de extraer nodos de texto |
| Pérdida de enlace silenciosa | Eliminar hipervínculos sin respaldo | Incluir la URL o anotarla a pie de página en lugar de descartarla. |
El HTML mal formado causa un tipo diferente de problema, ya que un analizador puede omitir contenido silenciosamente en lugar de generar un error.
Al ejecutar primero el marcado sospechoso a través de un embellecedor HTML (EN), a menudo aparecen etiquetas rotas o sin cerrar que de otro modo pasarían desapercibidas.
La doble decodificación merece una mención más por sí sola, aparte de la tabla anterior.
Ocurre con mayor frecuencia en tuberías con más de una etapa de procesamiento. Una etapa anterior ya decodifica entidades y una etapa posterior las decodifica nuevamente sin verificar.
La solución es de procedimiento, no técnica: registre cada punto del proceso donde ocurre la decodificación, y solo debería haber uno.
Preguntas frecuentes: Conversor de HTML a texto
¿Es la conversión de HTML a texto reversible volver al marcado original?
No. Una vez que se eliminan las etiquetas, los atributos y el estilo, esa información estructural desaparece para siempre.
Un archivo de texto sin formato contiene solo palabras, por lo que recrear el marcado significa reconstruir etiquetas y formatear desde cero, no revertir un proceso sin pérdidas.
¿Cuál es la diferencia entre HTML y la conversión de texto y la extracción de texto basada en OCR?
El OCR lee los píxeles de una imagen o fotografía escaneada y adivina los caracteres que ve, por lo que la precisión depende de la calidad de la imagen.
La conversión de HTML a texto lee el marcado que ya contiene caracteres reales, produciendo una salida determinista exacta cada vez.
¿Puede la conversión de HTML a texto conservar emojis y caracteres especiales Unicode?
Sí, siempre y cuando el documento fuente y el convertidor utilicen codificación basada en Unicode.
Los emoji, las letras acentuadas y las escrituras no latinas pasan intactos cuando las entidades se decodifican correctamente. Los problemas sólo aparecen cuando un convertidor asume por error una codificación más antigua y estrecha.
¿La conversión de HTML a texto afecta el SEO o crea problemas de contenido duplicado?
No directamente. Los motores de búsqueda indexan la página en vivo, no una copia de texto sin formato generada posteriormente.
El riesgo de contenido duplicado solo aparece si el texto extraído se vuelve a publicar en otro lugar de la web abierta sin cambios ni atribución.
Los convertidores de HTML a texto manejan las páginas renderizadas JavaScript de forma predeterminada
La mayoría no lo hace. Un convertidor estándar lee la fuente sin formato, por lo que el contenido inyectado más tarde por JavaScript nunca aparece.
Al emparejar el convertidor con una herramienta navegador sin cabeza como Puppeteer, Selenium o Playwright, la página se procesa primero y luego la extracción funciona normalmente.
¿Qué tamaño de archivo puede procesar un convertidor típico antes de que baje el rendimiento?
La mayoría de las bibliotecas manejan cómodamente documentos de hasta unos pocos megabytes sin problemas.
El rendimiento cae drásticamente en marcas profundamente anidadas o mal formadas. Las herramientas basadas en analizadores crean un árbol de documentos completo antes de extraer cualquier cosa, lo que cuesta más memoria en archivos más grandes.
¿Dónde se descompone un conversor de HTML a texto?
Un conversor de HTML a texto se descompone en tres puntos predecibles: codificación de caracteres no resueltos, contenido que existe sólo después de que se ejecuta JavaScript y marcado tan mal formado que ningún analizador puede crear un árbol de documentos utilizable.
Arreglar una conversión fallida sigue un orden específico y saltar hacia adelante desperdicia más tiempo del que ahorra.
- Verifica primero la codificación fuente
- En segundo lugar, comprueba si hay etiquetas mal formadas o sin cerrar.
- Prueba de contenido tercero dependiente de JavaScript
Los problemas de codificación corrompen todos los caracteres posteriores, por lo que aislarlos antes de que se preste atención a los problemas estructurales evita tener que reescribirlos más adelante.
Dirigir una página a través de un navegador sin cabeza antes de la conversión cierra la brecha JavaScript. Ese intercambio acepta un proceso de renderizado más lento con su propia memoria y un costo de alojamiento a cambio del texto completo.
Los lectores que manejan el flujo de trabajo inverso, convirtiendo un documento formateado en etiquetas publicables, normalmente se mueven junto a un convertidor dedicado de Palabra a HTML.