Cada grupo de 8 bits decodifica a un byte UTF-8. 01000001 = "A" (65), 00100000 = espacio (32).Los grupos pueden estar separados por espacios o agrupados en bloques de 8 bits. Los puntos de código no-ASCII (≥128) requieren secuencias UTF-8 de 2-4 bytes; las secuencias inválidas activan un error de parseo.
Salida de texto
Tabla de referencia binaria
| Binario | Carácter (código) |
|---|---|
| 01000001 | A (65) |
| 01000010 | B (66) |
| 01011010 | Z (90) |
| 01100001 | a (97) |
| 01111010 | z (122) |
| 00110000 | 0 (48) |
| 00111001 | 9 (57) |
| 00100000 | espacio (32) |
| 00100001 | ! (33) |
| 00111111 | ? (63) |
| 01000000 | @ (64) |
| 01111110 | ~ (126) |
Cómo convertir binario a texto
- Pega la cadena binaria.Pega tu código binario de 8 bits (separado por espacios o no) en la entrada.
- Consulta el texto decodificado.El texto legible aparece al instante en el área de salida.
- Comprueba el formato.Asegúrate de que cada byte tiene 8 bits — la herramienta admite ASCII y Unicode extendido.
- Copia el texto.Copia el texto decodificado al portapapeles para usarlo después.
Binario a Texto — Decodificar Código Binario a Texto Legible
Pega una cadena binaria — bytes separados por espacios (01001000 01100101...) o un flujo continuo — y la página la decodifica de vuelta a texto legible en tiempo real. El decodificador parte la entrada en grupos de 8 bits (el tamaño de byte estandarizado por ASA X3.4-1963 cuando ASCII se publicó el 17 de junio de 1963 con puntos de código de 7 bits; el 8º bit se reclamó primero para paridad y luego para codificaciones extendidas). Para entradas solo ASCII (U+0000–U+007F) cada grupo de 8 bits corresponde a un carácter. Para entradas UTF-8 (RFC 3629, Yergeau 2003), el decodificador sigue las reglas multi-byte: los puntos de código U+0080–U+07FF usan 2 bytes, U+0800–U+FFFF usan 3 bytes (el BMP, incluyendo la mayoría de escrituras no latinas) y los del plano suplementario U+10000+ usan 4 bytes. Los errores se muestran inline en vez de producir mojibake silencioso. Útil para ingeniería inversa de protocolos, decodificar volcados de dispositivos embebidos, aprender la estructura de bytes UTF-8 o comprobar que un flujo binario encaja con un patrón ASCII esperado.
Sobre esta herramienta
El decodificador corre íntegramente en el navegador. El parser de entrada tolera separadores de espacio en blanco (espacios, tabuladores, saltos de línea) y une flujos continuos en una única cadena de bits antes de partir en grupos de 8 bits — caracteres no binarios disparan un error inline en vez de corromper la alineación de bytes posterior. Cada byte se interpreta como una unidad de código UTF-8 según RFC 3629 §3, lo que significa que una entrada de 1 byte en U+0000–U+007F corresponde directamente a ASCII, y las secuencias multi-byte (byte líder 110xxxxx para 2 bytes, 1110xxxx para 3 bytes, 11110xxx para 4 bytes, con bytes de continuación 10xxxxxx) se validan contra las reglas de patrón de byte. Tres distinciones de codificación importan al leer datos binarios. ASCII (ASA X3.4-1963 → ANSI X3.4-1986) define 128 puntos de código en 7 bits. ASCII extendido (ISO 8859-1 / Latin-1 / Windows-1252) llega a 8 bits con caracteres regionales. UTF-8 (RFC 3629) cubre el repertorio Unicode 16.0 completo (~150.000 puntos de código) usando codificación de longitud variable. Un flujo binario por sí solo no transporta información de codificación — esa vive en cabeceras HTTP Content-Type, marcadores BOM (Byte Order Mark) según Unicode Standard 16.0 §2.6 o metadatos fuera de banda. Una codificación mal identificada produce 'mojibake' — caracteres visibles-pero-equivocados.
- Decodifica binario a texto ASCII / UTF-8 en tiempo real
- Gestiona bytes separados por espacios y flujos continuos de bits
- Alineación de byte de 8 bits según estándar ASA X3.4-1963 (ASCII)
- Gestión multi-byte UTF-8 según RFC 3629 (secuencias de 1, 2, 3 y 4 bytes)
- Error inline ante caracteres no válidos o entrada mal alineada
- Copia con un clic del texto decodificado al portapapeles
- Decodificación pura en cliente — sin llamada API, sin subida
- Reactivo — redecodifica mientras escribes o pegas
- Útil para ingeniería inversa de protocolos y depuración de dispositivos embebidos
Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).
Preguntas frecuentes
¿Por qué mi decodificador da basura?
Tres causas habituales: (a) desajuste de agrupación de bits — la entrada es un flujo continuo de 1s y 0s pero el decodificador la partió en grupos de 7 bits cuando la fuente era de 8 bits (o al revés); (b) desajuste de codificación — la entrada es base64 pero el decodificador la trata como binario crudo, o la entrada es binario que representa bytes UTF-8 pero el decodificador supone ASCII; (c) error de padding — entradas base64 sin los '=' finales confunden a decodificadores estrictos. Comprueba primero el formato fuente (binario vs base64 vs hex), luego alinea por byte (8 bits por carácter según ASA X3.4-1963).
¿Por qué base64 ocupa un 33% más que el binario original?
Base64 (RFC 4648) codifica cada 3 bytes de entrada (24 bits) como 4 caracteres de salida (cada uno transportando 6 bits = 24 bits totales). El alfabeto son 64 caracteres ASCII imprimibles (A–Z, a–z, 0–9, +, /), que caben en 6 bits por carácter. Resultado: 4 caracteres de salida por 3 bytes de entrada = 33,3% de expansión, más el padding '=' que añade hasta 2 caracteres al final. Base32 expande +60%, base16 (hex) +100%. El compromiso es intencionado: un alfabeto menor produce salida mayor pero transporta limpiamente por canales con plegado de mayúsculas, URL-encoding y otras restricciones.
¿Qué diferencia hay entre las codificaciones binaria, hex y base64?
Las tres son codificaciones de binario a texto (sin pérdida). Binario (base2) lista cada byte como 8 unos y ceros — 8× tamaño, bits totalmente legibles. Hex (base16, RFC 4648) agrupa cada 4 bits como 0–9/A–F — 2× tamaño, legible para hashes cortos, no distingue mayúsculas por especificación. Base64 (RFC 4648) empaqueta 6 bits por carácter — 1,33× tamaño, compacto para payloads largos (claves PEM, adjuntos email mediante MIME RFC 2045, data URIs). Elige por restricción de transporte: binario para inspección de bits legible, hex para identificadores cortos, base64 para transporte compacto sobre canales de texto.
¿Cómo detecto qué codificación usa un flujo binario?
Varias heurísticas: (a) BOM (Byte Order Mark) al inicio del flujo — 'EF BB BF' es UTF-8, 'FF FE' es UTF-16 LE, 'FE FF' es UTF-16 BE según Unicode Standard 16.0 §2.6; (b) parámetro 'charset=' de la cabecera HTTP Content-Type; (c) análisis estadístico — las secuencias UTF-8 tienen patrones de byte específicos (los bytes de continuación siempre empiezan con bits '10') según RFC 3629 §3. Ninguna es infalible. Un flujo UTF-8 sin BOM y sin Content-Type puede confundirse con Latin-1 — el modo de fallo es 'mojibake', caracteres visibles-pero-equivocados donde el decodificador eligió la codificación errónea y corrompió silenciosamente el texto.
¿Por qué los sistemas de email antiguos usan base64 aunque la red soporte binario?
SMTP (RFC 5321, Klensin 2008) aceptaba históricamente solo caracteres ASCII de 7 bits en cuerpos de mensaje — restricción heredada de canales telex de 7 bits. RFC 2045 (MIME, Freed & Borenstein 1996) estandarizó el marco para transportar contenido binario de 8 bits (imágenes, ejecutables, texto no ASCII) sobre transportes de 7 bits mediante valores Content-Transfer-Encoding: 7bit, 8bit, binary, quoted-printable, base64. SMTP moderno admite la extensión 8BITMIME, pero base64 sigue siendo el valor por defecto seguro — los gateways intermedios pueden descartar el 8º bit, y base64 sobrevive cualquier canal de 7 bits sin corrupción.
Fuentes (6)
- American Standards Association, X3.2 Subcommittee (1963). USA Standard Code for Information Interchange (ASCII), X3.4-1963. Published 17 June 1963 (7-bit, no lowercase); revised X3.4-1967 (added lowercase) and ANSI X3.4-1986 (final).
- Yergeau, F. (2003). UTF-8, a transformation format of ISO 10646. RFC 3629, IETF (STD 63).
- Freed, N., & Borenstein, N. (1996). Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, IETF (November 1996).
- Josefsson, S. (2006). The Base16, Base32, and Base64 Data Encodings. RFC 4648, IETF (October 2006; obsoletes RFC 3548).
- Klensin, J. (2008). Simple Mail Transfer Protocol. RFC 5321, IETF (defines 7-bit floor and 8BITMIME extension).
- The Unicode Consortium (2024). The Unicode Standard, Version 16.0 — Chapter 2 (General Structure) and §2.6 (Byte Order Mark). Unicode Consortium, Mountain View, CA.
Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.
Por Marco B. ·
Guías relacionadas
- Base64 en producción — Cuándo ayuda y cuándo noBase64 es un encoding de transporte, no compresión ni cifrado. Cuándo compensa su 33% de overhead en sistemas reales, y cuándo es un code smell a quitar.
- Codificación de caracteres para developers — ASCII, UTF-8, UTF-16La codificación de caracteres confunde a la gente décadas después de estar resuelta. El modelo mental: code points, encodings, BOMs, y por qué UTF-8 casi siempre gana.