Codificar / Decodificar Base64
Codifica y decodifica Base64 al instante. Incluye cálculo automático — útil para data URIs y pruebas de API.
Otras herramientas
Artículos relacionados
📖 Dónde se suele tropezar
Convierte texto o archivos a Base64 y de vuelta, con salida apta para URL y el salto de línea MIME clásico cada 76 caracteres. Todo se ejecuta en el navegador. Base64 es una codificación que representa bytes usando sólo 64 caracteres ASCII: no es cifrado ni compresión. Cualquiera puede revertirlo en un segundo, y los datos siempre crecen alrededor de un 33 por ciento. Prácticamente todos los incidentes con Base64 arrancan de confundir uno de esos dos puntos.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| El texto no ASCII se corrompe o lanza una excepción | Base64 opera sobre bytes, no sobre caracteres. El paso que convierte caracteres en bytes —elegir la codificación— ocurre fuera de Base64, y cuando emisor y receptor no coinciden en ella, el texto sale destrozado. En el navegador, btoa() sólo acepta el rango Latin-1, así que pasarle japonés lanza InvalidCharacterError. En cambio, base64_encode() de PHP codifica los bytes que le den, de modo que si el origen era Shift-JIS, Shift-JIS es lo que entra: y su silencio lo convierte en el caso más peligroso. |
Convierte a bytes UTF-8 antes de codificar. En JavaScript, obtén un Uint8Array con new TextEncoder().encode(str), codifica eso y decodifica con new TextDecoder().decode(bytes) a la vuelta. Mientras ese viaje de ida y vuelta sea simétrico, no se corrompe nada entre ningún par de lenguajes. Cuando los datos cruzan la frontera de un sistema, indica en la documentación de la API que la carga en Base64 es UTF-8: la codificación no puede recuperarse de la propia cadena Base64, así que si no lo dices, el otro lado adivina. |
| Se rompe al meterlo en una URL o en la cadena de consulta | Los caracteres +, / y = del Base64 estándar significan otra cosa dentro de una URL. El peligroso es +, que una cadena de consulta lee como espacio, con lo que el valor se corrompe al decodificar. Lo desagradable es que el fallo parece probabilístico: que la salida contenga un + depende de la entrada, así que se manifiesta pasando todas las pruebas y fallando luego con un registro concreto en producción. / choca con el separador de ruta y = con la asignación de parámetros. |
Usa la forma apta para URL cuando vaya en una URL: + pasa a -, / pasa a _ y se elimina el = final (base64url en la RFC 4648). JWT está estandarizado exactamente así, de modo que construir un JWT a mano no te deja elección. Ante la duda, elige URL-safe desde el principio en vez de codificar en porcentaje una cadena Base64 estándar: la doble codificación suele acabar con una sola capa deshecha y un %2B perdido en tus datos. Quitar el relleno = es seguro, porque la longitud lo determina. |
| Incrustarlo como data URI lo dejó más lento | Sí eliminas una petición, pero los datos crecen un 33 por ciento y la caché del navegador deja de aplicar. Incrusta una imagen en el CSS y la hoja de estilos se hincha, y las hojas de estilo bloquean el renderizado, así que el primer pintado se ralentiza. Veinte imágenes de 10KB convierten lo que habrían sido veinte peticiones paralelas en un único recurso de 266KB que bloquea el renderizado. Peor aún: cambiar una sola imagen invalida la caché de toda la hoja de estilos. Desde HTTP/2 el coste de una petición extra ha caído mucho, así que la premisa de que hay que minimizar peticiones está desfasada. | Reserva los data URI para iconos pequeños, de unos pocos kilobytes. Por encima de eso, cárgalo como un <img> normal y quédate con las ventajas de la caché y de las imágenes adaptativas (srcset): sale más rápido. No conviertas un SVG a Base64: el SVG es texto, así que codificarlo en porcentaje con encodeURIComponent es más pequeño que Base64 y además comprime con gzip. La regla de decisión es simple: compara cada cuánto cambia la imagen con cada cuánto se sirve la hoja de estilos. Sólo recursos como un logotipo, que apenas cambian y se usan en todas las páginas, son buenos candidatos. |
Base64 no es ni siquiera ofuscación. Escribir password: cGFzc3dvcmQ= en un archivo de configuración lo hace ilegible de un vistazo y nada más; no es un secreto. Los Secrets de Kubernetes usan exactamente esta forma, y eso es codificación, no cifrado: cualquiera que vea la salida de kubectl get secret -o yaml puede decodificarlo, y por eso se añaden encima gestores de secretos externos y cifrado en reposo. El escaneo de secretos de GitHub y otros detectores de fugas decodifican Base64 y miran dentro, así que subirlo se detecta con toda normalidad. Dicho al revés: cualquier sitio donde alguien decidió que bastaba con estar en Base64 es casi seguro una vulnerabilidad. Una cosa más: vigila cómo se manejan los saltos de línea. El correo y el formato PEM cortan el texto cada 64 a 76 caracteres, y algunas implementaciones dan error si decodificas sin quitar esos saltos, mientras que ciertos sistemas antiguos rechazan la entrada si llega en una sola línea larga.
📖 Cómo usar
-
1
Pega la entradaPega texto para codificar o Base64 para decodificar.
-
2
Cambia direcciónPulsa Encode/Decode.
-
3
Elige URL-safePara URLs o JWT, elige URL-safe.
❓ Preguntas frecuentes
¿Por qué Base64 aumenta 33%?
¿Maneja archivos binarios?
¿Se envían los datos?
¿Cómo se manejan las nuevas líneas?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.