Codificador/Decodificador Base64
Codifique, decodifique e inspeccione Base64 y Data-URIs sin latencia. Incluye detección inteligente de carga útil, inspector de JSON Web Token (JWT) en tiempo real, generador de Data-URI para imágenes, auditor de sobrecarga Base64 y conmutador RFC 4648 URL-Safe con privacidad 100% en el cliente.
Herramientas en LíneaTabla de Índice del Alfabeto Base64 RFC 4648 (64 Caracteres)
Mapeo completo de secuencias binarias de 6 bits a conjuntos de caracteres estándar y URL-Safe.
| Valor (Decimal) | Binario (6 Bits) | Carácter Base64 | Carácter URL-Safe | Hexadecimal ASCII |
|---|---|---|---|---|
| 0 | 000000 | A | A | 0x41 |
| 1 | 000001 | B | B | 0x42 |
| 2 | 000010 | C | C | 0x43 |
| 3 | 000011 | D | D | 0x44 |
| 4 | 000100 | E | E | 0x45 |
| 5 | 000101 | F | F | 0x46 |
| 6 | 000110 | G | G | 0x47 |
| 7 | 000111 | H | H | 0x48 |
| 8 | 001000 | I | I | 0x49 |
| 9 | 001001 | J | J | 0x4A |
| 10 | 001010 | K | K | 0x4B |
| 11 | 001011 | L | L | 0x4C |
| 12 | 001100 | M | M | 0x4D |
| 13 | 001101 | N | N | 0x4E |
| 14 | 001110 | O | O | 0x4F |
| 15 | 001111 | P | P | 0x50 |
| 16 | 010000 | Q | Q | 0x51 |
| 17 | 010001 | R | R | 0x52 |
| 18 | 010010 | S | S | 0x53 |
| 19 | 010011 | T | T | 0x54 |
| 20 | 010100 | U | U | 0x55 |
| 21 | 010101 | V | V | 0x56 |
| 22 | 010110 | W | W | 0x57 |
| 23 | 010111 | X | X | 0x58 |
| 24 | 011000 | Y | Y | 0x59 |
| 25 | 011001 | Z | Z | 0x5A |
| 26 | 011010 | a | a | 0x61 |
| 27 | 011011 | b | b | 0x62 |
| 28 | 011100 | c | c | 0x63 |
| 29 | 011101 | d | d | 0x64 |
| 30 | 011110 | e | e | 0x65 |
| 31 | 011111 | f | f | 0x66 |
| 32 | 100000 | g | g | 0x67 |
| 33 | 100001 | h | h | 0x68 |
| 34 | 100010 | i | i | 0x69 |
| 35 | 100011 | j | j | 0x6A |
| 36 | 100100 | k | k | 0x6B |
| 37 | 100101 | l | l | 0x6C |
| 38 | 100110 | m | m | 0x6D |
| 39 | 100111 | n | n | 0x6E |
| 40 | 101000 | o | o | 0x6F |
| 41 | 101001 | p | p | 0x70 |
| 42 | 101010 | q | q | 0x71 |
| 43 | 101011 | r | r | 0x72 |
| 44 | 101100 | s | s | 0x73 |
| 45 | 101101 | t | t | 0x74 |
| 46 | 101110 | u | u | 0x75 |
| 47 | 101111 | v | v | 0x76 |
| 48 | 110000 | w | w | 0x77 |
| 49 | 110001 | x | x | 0x78 |
| 50 | 110010 | y | y | 0x79 |
| 51 | 110011 | z | z | 0x7A |
| 52 | 110100 | 0 | 0 | 0x30 |
| 53 | 110101 | 1 | 1 | 0x31 |
| 54 | 110110 | 2 | 2 | 0x32 |
| 55 | 110111 | 3 | 3 | 0x33 |
| 56 | 111000 | 4 | 4 | 0x34 |
| 57 | 111001 | 5 | 5 | 0x35 |
| 58 | 111010 | 6 | 6 | 0x36 |
| 59 | 111011 | 7 | 7 | 0x37 |
| 60 | 111100 | 8 | 8 | 0x38 |
| 61 | 111101 | 9 | 9 | 0x39 |
| 62 | 111110 | + | - | 0x2B |
| 63 | 111111 | / | _ | 0x2F |
Arquitectura Matemática del Relleno Base64 (=)
Por qué se utiliza el relleno y cómo la alineación de 24 bits determina los signos igual.
Mecanismo de Transformación de 3 Bytes a 4 Caracteres
Base64 agrupa tres octetos de 8 bits (24 bits en total) y los transforma en cuatro índices de 6 bits. Cuando la entrada no es divisible exactamente entre 3, el bloque final requiere relleno.
Cuando el número de bytes es múltiplo de 3, se obtienen exactamente 4 caracteres Base64 por cada 3 bytes. No se añade ningún signo de relleno (=).
Hay 8 bits disponibles. Se toman 6 bits para el primer carácter y los 2 bits restantes se completan con 4 ceros. Se añaden dos signos de relleno (==).
Hay 16 bits disponibles. Se generan dos caracteres de 6 bits (12 bits) y los 4 bits sobrantes se completan con 2 ceros. Se añade un único signo de relleno (=).
La Penalización del +33.3% de Sobrecarga en la Web Moderna
Base64 convierte 3 bytes binarios en 4 caracteres ASCII, inflando el tamaño sin comprimir en un 33.33%. Aunque la incrustación ahorra una petición HTTP, la memoria requerida y la falta de caché pueden afectar el rendimiento.
Buenas Prácticas para Desarrolladores: Cuándo Incrustar y Cuándo Vincular
Favicons y micro SVGs se benefician de Data URIs al evitar peticiones adicionales durante la pintura inicial.
Con protocolos modernos, incrustar imágenes medianas o grandes suele ser contraproducente debido a la falta de almacenamiento en caché del navegador.
Para cabeceras de autorización y tokens JWT, Base64 asegura compatibilidad en medios basados en texto, pero no debe considerarse cifrado.
Cómo Usar el Codificador y Decodificador Base64 (Paso a Paso)
Domine la codificación de texto, conversión de archivos binarios, transferencias URL-Safe e inspección de JWT.
Seleccione el Modo de Operación o Use la Detección Automática
Elija 'Detección automática' para clasificar su entrada en tiempo real, o seleccione 'Codificar', 'Decodificar', 'Inspector JWT' o 'Generador Data-URI' en la barra superior.
Introduzca Texto, Pegue Hashes o Suba Archivos
Escriba o pegue cadenas UTF-8, hashes Base64 o tokens JWT en el terminal. También puede arrastrar y soltar archivos (imágenes, SVGs, documentos) para generar Data-URIs al instante.
Active el Modo Seguro para URLs (RFC 4648 §5)
Active el interruptor 'URL-Safe' para reemplazar '+' por '-' y '/' por '_', y eliminar el relleno '=' final, garantizando compatibilidad absoluta con enlaces web y parámetros de consulta.
Inspeccione Cargas Decodificadas y Vistas Previas
Al analizar JWTs, examine encabezados formateados, claims y estado de expiración. Al subir imágenes, disfrute de una vista previa en vivo junto con fragmentos listos para HTML y CSS.
Audite el Incremento de Tamaño y Sobrecarga de Datos
Compruebe el Auditor de Sobrecarga para monitorear el aumento exacto del +33,3% en bytes y evaluar si la inserción en línea (inline) resulta conveniente para su caso de uso.
Copie al Portapapeles o Descargue el Resultado
Haga clic en 'Copiar al portapapeles' para usar el resultado en su código, o descárguelo como archivo. Todo el procesamiento es 100% privado y se ejecuta en su navegador.
Preguntas Frecuentes (FAQ)
Respuestas técnicas y prácticas para desarrolladores web, ingenieros de seguridad y administradores de sistemas.
Q:¿Qué es la codificación Base64 y para qué se utiliza?
Base64 es un sistema de codificación binario a texto especificado en el estándar RFC 4648. Convierte secuencias de bytes binarios en un conjunto de 64 caracteres ASCII imprimibles (A–Z, a–z, 0–9, +, /). Se utiliza principalmente para transmitir datos binarios—como imágenes, claves criptográficas o certificados digitales—a través de protocolos diseñados para texto (HTTP, correos electrónicos SMTP, JSON y XML) sin riesgo de corrupción por caracteres de control.
Q:¿Cuál es la diferencia entre Base64 Estándar y Base64 URL-Safe?
Base64 Estándar (RFC 4648 §4) utiliza los símbolos '+' y '/' junto con '=' para el relleno. Sin embargo, en direcciones URL y parámetros de consulta HTTP, el '+' suele interpretarse como un espacio y el '/' actúa como separador de rutas. Base64 URL-Safe (RFC 4648 §5) sustituye '+' por '-' (guion) y '/' por '_' (guion bajo), y habitualmente suprime el relleno '=' final para evitar conflictos.
Q:¿Por qué Base64 incrementa el tamaño de los datos en aproximadamente un 33%?
Base64 toma bloques de 3 bytes (24 bits) de información binaria y los transforma en 4 caracteres ASCII (32 bits), dado que cada carácter Base64 almacena únicamente 6 bits de información. Esta relación matemática de 4 a 3 genera un aumento exacto del 33,33% en el peso de los datos sin comprimir, más los posibles caracteres de relleno.
Q:¿Qué significan los signos de igual (=) al final de una cadena Base64?
El signo de igual '=' es un carácter de relleno (padding) que garantiza que los datos encajen en bloques de 24 bits. Si la longitud de entrada no es divisible entre 3, se rellenan con ceros: si sobra 1 byte, se añaden dos signos '=='; si sobran 2 bytes, se añade un único signo '='; si la longitud es un múltiplo exacto de 3, no se añade ningún relleno.
Q:¿Cómo funciona el Inspector de JWT y qué tan seguro es?
Un JSON Web Token (JWT) consta de tres partes separadas por puntos: Encabezado, Carga Útil (Payload) y Firma. Nuestro inspector desglosa el token y decodifica las partes Base64URL para mostrar claims, fechas de expiración y algoritmos. Dado que toda la operación se realiza en la memoria local de su navegador, sus tokens, credenciales y firmas nunca se transmiten por la red.
Q:¿Cuándo conviene incrustar imágenes como Data-URI frente a vincularlas externamente?
Las Data-URIs son recomendables para recursos minúsculos (menores a 2 KB), tales como favicons, micro-iconos o SVGs críticos, ya que reducen peticiones HTTP iniciales. Para imágenes de mayor tamaño (> 10 KB), es preferible enlazarlas como archivos externos, puesto que Base64 añade un 33% de peso y el navegador no puede almacenar la imagen de forma independiente en su memoria caché.
Q:¿Se envía información privada, contraseñas o archivos a servidores externos?
No. El 100% de la codificación, decodificación, lectura de archivos y análisis sintáctico se ejecuta exclusivamente en el navegador mediante APIs estándar de JavaScript (FileReader y TextEncoder/TextDecoder). Ningún dato sale de su dispositivo.
¿Qué es Codificador/Decodificador Base64?
Lidiar con cadenas de texto interminables puede ser un dolor de cabeza si no tienes las herramientas adecuadas. Nuestra plataforma de codificación Base64 está diseñada para eliminar la fricción del desarrollo diario, ofreciendo resultados instantáneos sin recargar la página (latencia cero). Lo que hace única a esta herramienta es su enfoque en la privacidad y el rendimiento: al procesar todo directamente en tu dispositivo, puedes auditar datos confidenciales sin miedo a fugas de información.
Caso de Uso: Resolviendo cuellos de botella en APIs móviles
Una desarrolladora de aplicaciones móviles está notando que las solicitudes a su API REST tardan demasiado en completarse. La aplicación permite a los usuarios subir fotos de perfil, las cuales se están enviando codificadas en Base64. Al utilizar el Auditor de Sobrecarga (Bloat Auditor) de nuestra plataforma, descubre visualmente la penalización arquitectónica: codificar imágenes pesadas añade un 33.3% extra al tamaño original del archivo. Con esta información respaldada por datos precisos, decide reescribir la API para usar cargas multiparte (multipart/form-data) en lugar de cadenas de texto, mejorando drásticamente el rendimiento de la app.
Resolución de Problemas Comunes
| Problema Frecuente | Solución en la Herramienta | Resultado |
|---|---|---|
| Errores de sintaxis en URLs | Activar el modo "URL-Safe" (RFC 4648). | Reemplaza los caracteres conflictivos (+, /) haciéndolo seguro para hipervínculos. |
| Imágenes que no cargan en CSS | Usar el constructor de Data-URI. | Genera el prefijo exacto (data:image/png;base64,...) listo para copiar y pegar. |
| Inseguridad con datos privados | Arquitectura 100% Client-Side. | Garantiza que las cadenas decodificadas nunca abandonen la memoria de tu navegador. |
Historia y Origen
El concepto de padding (el uso del signo = al final de las cadenas) siempre ha generado confusión. Históricamente, Base64 procesa los datos en bloques de 3 bytes. Si el archivo que estás convirtiendo no es un múltiplo exacto de 3, el algoritmo no sabe cómo terminar el proceso. Para solucionar esta desalineación, los ingenieros que redactaron los primeros estándares RFC introdujeron el carácter de relleno =. Esto le indica al decodificador exactamente cuántos bytes ficticios se añadieron para completar la secuencia matemática.