Convertidor de texto a hexadecimal UTF-8

ñ es C3 B1: cuántos bytes ocupa un carácter en UTF-8

Convertir a hexadecimal UTF-8 significa pasar el texto a los bytes que el ordenador guarda de verdad y escribir cada byte con dos cifras hexadecimales, de 00 a FF. La letra ñ tiene el número Unicode (punto de código) U+00F1 y se guarda como los dos bytes C3 B1. Una A sin más es el byte 41, y el emoji 😀 son los cuatro bytes F0 9F 98 80. En sentido contrario, si pegas C3 B1 desde un log o un depurador, vuelves a obtener ñ.

Los dos cuadros de arriba se pueden editar, y el que modificas pasa a ser el original. La banda central escribe cada carácter con sus bytes debajo, como un subtítulo, y un color bajo cada byte indica si el carácter ocupa 1, 2, 3 o 4 bytes. Si pulsas un carácter, la lupa de bits muestra qué bits de su punto de código caen en cada byte UTF-8. El hexadecimal se puede escribir separado por espacios, seguido, como matriz 0x, con escapes \x o con codificación %, y al pegar se entienden los cinco.

Cuándo hace falta ver los bytes UTF-8

• Un log muestra \xc3\xb1 donde debería haber una letra: Python escribe los bytes fuera de ASCII como escapes \x, así que año guardado en UTF-8 aparece como b'a\xc3\xb1o'. Pega la línea entera en el cuadro hexadecimal, con las comillas y las letras sueltas, y el conversor la lee de nuevo como año.
• MySQL rechaza un emoji: utf8mb3 (antes llamado utf8) guarda como máximo 3 bytes por carácter, así que un carácter de 4 bytes como un emoji falla con el error 1366 y un mensaje parecido a Incorrect string value: '\xF0\x9F\x98\x80'. Si pegas esos bytes en el conversor, ves que 😀 es un solo carácter que necesita cuatro bytes.
• Dos textos que se ven iguales pero no coinciden: un espacio de no separación (C2 A0), un espacio de ancho cero (E2 80 8B) y la marca de orden de bytes al principio de un archivo (EF BB BF) no se ven en pantalla, pero sus bytes son distintos. La banda los etiqueta como NBSP, ZWSP y BOM.
• Un nombre de archivo con tilde no coincide: un volumen de Mac con HFS Plus guarda los nombres con una variante de la forma descompuesta (NFD), de modo que canción.txt puede llegar como una o, una tilde suelta y una n. Pasa de 12 a 13 bytes, y el conversor te dice qué resultaría al componerlo en NFC.
• Leer %C3%B1 en una dirección: una URL lleva el texto no ASCII convirtiéndolo antes a UTF-8 y escribiendo cada byte como % más dos cifras hexadecimales. Si pegas %61%C3%B1%6F, sale año.
• Meter una cadena en una matriz de bytes en el código: el firmware embebido y los protocolos de red suelen pedir 0x61, 0xC3, 0xB1, 0x6F. Elige el formato "Matriz 0x" y el conversor lo escribe de forma que puedes pegarlo directamente en el código fuente.
• La ñ o las tildes se convierten en letras raras: un texto como canción que aparece como canción, o como canci�n, indica que unos bytes UTF-8 se leyeron como Windows-1252, o al revés. Pon los bytes originales en el cuadro hexadecimal y el conversor muestra si son UTF-8 válido y cómo se leen en Windows-1252.

Cómo se usa

1. Escribe texto en el cuadro de texto o pega bytes en el cuadro hexadecimal. La página se abre con un ejemplo, y los botones de arriba cargan caracteres ocultos, una tilde descompuesta, bytes \x de un log y bytes dañados.
2. Las flechas entre los cuadros indican el sentido. Si editas el texto, la conversión va hacia abajo (codificar); si editas el hexadecimal, va hacia arriba (decodificar).
3. Elige un formato hexadecimal y mayúsculas o minúsculas. Si ya hay hexadecimal en el cuadro, al cambiar el formato se reescriben los mismos bytes con el estilo nuevo.
4. Pulsa un carácter de la banda, o mueve el cursor en un cuadro, y la lupa de bits muestra su punto de código, sus bytes en UTF-8, UTF-16 y Windows-1252 y su posición.
5. Con "Copiar hexadecimal" o "Copiar texto" te llevas el resultado. El panel de abajo a la derecha compara cuántos bytes ocupa el mismo texto en UTF-16 y en Windows-1252.

Cómo reparte UTF-8 un carácter en bytes

UTF-8 escribe cada carácter de U+0000 a U+10FFFF con 1 a 4 bytes (RFC 3629). El primer byte empieza con unos bits que indican cuántos bytes tiene el carácter, y todos los bytes siguientes empiezan por 10. Por eso, mirando un solo byte, se sabe si empieza un carácter o continúa uno.

Hagámoslo a mano con €. U+20AC en binario es 0010 0000 1010 1100, dieciséis bits. El patrón de 3 bytes tiene sitio para 4 + 6 + 6 bits, así que se divide en 0010 / 000010 / 101100 y se coloca en 11100010, 10000010, 10101100. Esos tres bytes son E2, 82 y AC en hexadecimal. De U+0000 a 007F el byte es el propio punto de código, por lo que un texto formado solo por letras inglesas, cifras y signos de puntuación ASCII tiene los mismos bytes en ASCII y en UTF-8.

Las vocales con tilde, la ñ, la ü y los signos ¿ y ¡ están en la fila de 2 bytes, y por eso canción tiene 7 caracteres pero 8 bytes. Las comillas tipográficas, la raya y el signo del euro están en la fila de 3 bytes, y casi todos los emojis necesitan cuatro.

Bytes por carácter en UTF-8, UTF-16 y Windows-1252

Windows-1252 es una codificación de un byte, y sus bytes 80 a 9F contienen caracteres como el signo del euro (80), las comillas tipográficas (93 y 94) y la raya (97). En la tabla del navegador, las etiquetas latin1 e iso-8859-1 también se tratan como windows-1252, por eso una página declarada como "Latin-1" suele mostrar bien esos caracteres. Todo lo que queda fuera de sus 256 valores, como Ω, 日 o un emoji, simplemente no se puede guardar en ella.

El mismo texto, otra cantidad de bytes

Con letras inglesas UTF-8 es lo más corto, y UTF-16 gasta siempre al menos dos bytes por unidad de código. La fila ¡Sí! 5 € muestra el coste de los signos del español: ocho caracteres ocupan 12 bytes en UTF-8, porque ¡, í y € no son ASCII, mientras que Windows-1252 los guarda en ocho. Esa economía de un byte explica por qué los archivos antiguos la usaban, y también por qué se rompen cuando los mismos bytes se leen como UTF-8. El emoji de familia parece un solo carácter en pantalla, pero son tres emojis de persona (4 bytes cada uno) unidos por dos ZWJ (3 bytes cada uno), y por eso ocupa 18 bytes.

Cinco formas de escribir el hexadecimal

Al pegar no hace falta elegir formato. Espacios, tabuladores, saltos de línea, comas, dos puntos y guiones se tratan como separadores, de modo que el 61-C3-B1-6F que escribe BitConverter.ToString de .NET entra tal cual. En los formatos \x y % también se leen como bytes las letras y cifras sueltas escritas entre los escapes, y se quitan envoltorios como b'…', "…" o […]. La RFC 3986 recomienda mayúsculas en la codificación porcentual, pero mayúsculas y minúsculas son los mismos bytes.

// JavaScript: texto → hexadecimal UTF-8
[...new TextEncoder().encode('año')].map(b => b.toString(16).padStart(2, '0')).join(' ');  // '61 c3 b1 6f'

# Python 3.8 o posterior: texto ↔ hexadecimal
'año'.encode('utf-8').hex(' ')                    # '61 c3 b1 6f'
bytes.fromhex('61 C3 B1 6F').decode('utf-8')      # 'año' (los espacios se ignoran)

Bytes que no son UTF-8 válido

No toda secuencia de bytes es UTF-8. Un byte de continuación sin byte inicial, un carácter cortado por la mitad o un carácter escrito con más bytes de los necesarios dan UTF-8 no válido. La RFC 3629 prohíbe codificar el rango de sustitutos (U+D800 a DFFF) y avisa de que un decodificador no debe aceptar formas superlargas (overlong) como C0 80. Un navegador pone un carácter de reemplazo � (U+FFFD) por cada parte no válida; este conversor divide los bytes con la misma regla y marca en la banda los bytes erróneos y el motivo.

Como en las dos últimas filas, un carácter cortado se sustituye como un todo: los bytes que eran válidos hasta ese punto se agrupan en un único �. Unicode lo llama sustituir la "subparte máxima" (maximal subpart), y los mismos bytes dan el mismo número de � en un navegador y en este conversor. Mientras escribes en el cuadro hexadecimal, un último carácter a medias no se trata como error; el conversor te dice cuántos bytes faltan y solo lo juzga cuando sales del cuadro.

Deducir la codificación original a partir del texto estropeado

La mayoría del texto estropeado, llamado mojibake, viene de bytes guardados con una codificación y leídos con otra. La basura tiene sus costumbres, y su aspecto indica en qué sentido se cometió el error.

Si una letra con tilde se convierte en à o  seguida de otro símbolo, y una raya o el euro se convierten en â seguida de €, ‚ o similares, se leyó UTF-8 como Windows-1252. Si en cambio las tildes y la ñ se convierten en �, lo más probable es que el texto fuera Windows-1252 leído como UTF-8, porque un byte como F1 o F3 seguido de una letra ASCII no es UTF-8 válido. Pon los bytes originales en el cuadro hexadecimal y el conversor prueba primero UTF-8; si falla, escribe debajo la lectura en Windows-1252. El ejemplo "Bytes dañados", 61 F1 6F 20 79 20 63 61 6E 63 69 F3 6E, es el texto "año y canción" guardado en Windows-1252.

Errores frecuentes

• Esperar un cambio de base numérica: si escribes 255 en el cuadro de texto, obtienes 32 35 35, los bytes de los caracteres de cifra 2, 5 y 5, no FF. Para cambiar la base de un número usa un conversor de bases.
• Mezclar puntos de código con bytes UTF-8: U+00F1 es el número de la ñ, mientras que C3 B1 es ese número guardado en UTF-8. Si pones U+00F1 o \u00F1 en el cuadro hexadecimal, aparece un aviso de que eso no son bytes.
• Tomar el hexadecimal por cifrado: el hexadecimal es solo una forma de escribir bytes, y cualquiera puede volver a convertirlo en texto. No lo uses para ocultar contraseñas ni datos personales.
• No saber si hay que quitar un EF BB BF inicial: es la marca de orden de bytes UTF-8 (U+FEFF), y al principio de un archivo sirve solo como firma. La FAQ de Unicode dice que los protocolos de bytes que esperan caracteres ASCII al principio deben evitarla, y también que un protocolo, como las convenciones de Microsoft para archivos .txt, puede exigirla. Comprueba qué hace el programa receptor antes de conservarla o quitarla.
• Esperar el salto de línea de Windows 0D 0A: los cuadros de entrada del navegador guardan el salto de línea como LF (0A). Un salto que escribes en el cuadro de texto es 0A; para inspeccionar un CR (0D), escribe 0D 0A en el cuadro hexadecimal.
• Contar igual caracteres y bytes: donde un límite de longitud cuenta bytes, "Hola, canción" cuesta 14 bytes para 13 caracteres, y los emojis cuestan más. Lee juntos los tres números sobre la banda: caracteres, puntos de código y bytes.

Límites

• La conversión se hace solo en tu navegador. El texto y los bytes que escribes no se envían a ningún servidor ni se guardan en la dirección ni en el almacenamiento.
• El texto se convierte hasta 100.000 posiciones UTF-16 cada vez y el hexadecimal hasta 1.200.000 posiciones, con los separadores. La banda dibuja solo los primeros 1.500 caracteres y bytes erróneos; el resto se sigue convirtiendo y copiando.
• La salida hexadecimal contiene solo bytes UTF-8. UTF-16 y Windows-1252 aparecen únicamente en la comparación de bytes y como valores por carácter en la lupa de bits.
• Los valores de Windows-1252 siguen la tabla WHATWG Encoding del navegador, así que un programa antiguo puede diferir en algunos caracteres.
• El texto nunca se normaliza automáticamente. El texto descompuesto (NFD) solo provoca un aviso, y cambia únicamente cuando pulsas "Componer en NFC".
• No se admiten archivos binarios arbitrarios como imágenes o archivos comprimidos. Para pasar un archivo a texto usa una herramienta de Base64.
• Al leer la codificación %, el + se queda como signo más (2B) y no como espacio. Para datos de formularios, donde + significa espacio, usa un codificador/decodificador de URL.

Fuentes

Base: las reglas de UTF-8 salen de la RFC 3629 y del capítulo 3 de The Unicode Standard 18.0, la codificación y decodificación del navegador y la tabla de Windows-1252 del estándar WHATWG Encoding, y los demás formatos y mensajes de los documentos siguientes, todos comprobados el 21 de octubre de 2026. Las reglas de bytes de UTF-8 no han cambiado desde la RFC 3629.

• 01RFC 3629 — UTF-8, a transformation format of ISO 10646U+0000 a 10FFFF con 1 a 4 bytes, sustitutos prohibidos, aviso sobre la forma superlarga C0 80, el BOM es EF BB BF
• 02The Unicode Standard 18.0 — Capítulo 3, ConformanceTabla 3-7 secuencias de bytes UTF-8 bien formadas, 3.9.6 sustitución de la subparte máxima por U+FFFD
• 03WHATWG — Encoding StandardDecodificador UTF-8, TextDecoder fatal e ignoreBOM, las etiquetas latin1 e iso-8859-1 equivalen a windows-1252
• 04Unicode — UTF-8, UTF-16, UTF-32 & BOM FAQUn BOM inicial es una firma; evitarlo en protocolos de bytes que esperan ASCII, aunque algunas convenciones lo exigen
• 05RFC 3986 — URI Generic Syntax2.1 codificación porcentual, se recomiendan mayúsculas; 2.5 convertir a UTF-8 y luego codificar con %
• 06MySQL 8.4 — The utf8mb3 Character SetMáximo 3 bytes por carácter, solo caracteres BMP (sin caracteres suplementarios), utf8 es un alias en desuso
• 07MySQL 8.4 — Server Error Message ReferenceError 1366 ER_TRUNCATED_WRONG_VALUE_FOR_FIELD: Incorrect %s value: '%s' for column
• 08Python 3 — Tipos integrados: bytesbytes.fromhex ignora los espacios ASCII, bytes.hex(sep) desde 3.8, bytes fuera de ASCII mostrados como escapes \x
• 09Microsoft Learn — BitConverter.ToStringPares hexadecimales unidos por guiones, por ejemplo "7F-2C-4A-00"
• 10MDN — TextEncoderCodifica siempre una cadena de JavaScript como UTF-8
• 11MDN — String: lengthCuenta unidades de código UTF-16, no caracteres
• 12Unicode Technical Standard #51 — Unicode EmojiRevisión 31 (Emoji 18.0), secuencias de emojis unidas con ZWJ
• 13Unicode Standard Annex #15 — Normalization FormsRevisión 58, NFD = descomposición canónica, NFC = descomposición canónica seguida de composición canónica
• 14Apple Technical Q&A QA1173 — Text Encodings in VFSHFS Plus (Mac OS Extended) usa una variante de la forma normal D para los nombres de archivo

Preguntas frecuentes

Herramientas relacionadas