> codificador base64 | texto | archivo <

Escribe o pega tu texto en el área ENTRADA de arriba. Auto-encode está activado por defecto — el resultado Base64 aparece en el área SALIDA mientras escribes. Haz clic en [ENCODE] o pulsa Ctrl/Cmd + Intro para activar la codificación manualmente. Activa --url-safe o --no-padding según dónde se use el Base64 (JWT, OAuth, URLs → ambos activados). Todo se ejecuta localmente en tu navegador: sin subidas, sin logs, sin solicitudes de red ligadas a tu entrada.

Haz clic en el botón [upload file] debajo del área de entrada y elige un archivo de hasta 100 MB. El codificador lo lee con FileReader.readAsArrayBuffer, pasa los bytes en flujo por btoa en bloques de 32 KB (para que archivos grandes no bloqueen el navegador) y escribe el Base64 completo en el área SALIDA. Para archivos más grandes, usa un codificador de línea de comandos: base64 < input.bin > output.txt (macOS/Linux), o PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Si quieres el Base64 formateado como Data URI (p. ej. data:image/png;base64,...), antepón el tipo MIME y ;base64, a la salida, o usa nuestra herramienta dedicada Imagen a Base64, que produce Data URIs listos para pegar para PNG, JPG, GIF, WebP y SVG.

Las tres están definidas en RFC 4648:

• Base64 estándar (§4) usa el alfabeto A-Z a-z 0-9 + / con padding =. La longitud de salida siempre es múltiplo de 4. Seguro para MIME, HTTP Basic Auth y valores de cadena JSON.

• Base64 URL-safe (§5) reemplaza + por - y / por _. Requerido cuando el Base64 se coloca en rutas URL, parámetros de consulta, nombres de archivo o segmentos JWT — los caracteres estándar +/ necesitarían codificación porcentual de otro modo.

• Sin padding (tanto §4 como §5, base64url sin padding) elimina los caracteres = finales. La longitud ya no es múltiplo de 4, pero los decodificadores pueden calcular la longitud original a partir del resto mod 4. Usado por JWT (base64url según RFC 7515), WebAuthn y algunas implementaciones CBOR/COSE.

Hay que indicar a los decodificadores qué variante esperar — nuestro Decodificador Base64 auto-detecta las tres.

Todos los lenguajes y runtimes principales incluyen codificación Base64. Fragmentos listos para copiar y pegar:

JavaScript (navegador):
btoa('Hello') // SGVsbG8=
// Para UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 safe

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-safe, sin pad

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-safe sin pad

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (sin pad)
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=. Usa base64 -w 0 en Linux para suprimir el ajuste de línea a 76 columnas.

La salida Base64 es ~33 % mayor que la entrada: cada 3 bytes de entrada se convierten en 4 caracteres de salida. Fórmula exacta: ceil(n / 3) × 4 incluyendo padding, o ceil(n × 4 / 3) sin él. Más unos bytes extra de sobrecarga si ajustas la línea a 76 columnas (MIME) o 64 columnas (PEM).

Ejemplos:
• 1 KB binario → ~1,37 KB Base64
• imagen de 100 KB → ~137 KB Data URI
• PDF de 1 MB → ~1,37 MB Base64 en JSON

Cuándo evitar Base64:
• Transferencias de archivos grandes: una imagen de 10 MB incrustada como Base64 en HTML se convierte en 13,7 MB de texto parseado, bloquea el hilo principal y no puede cachearse por separado. Prefiere <img src="/assets/photo.png">.
• APIs críticas para el rendimiento: un payload Base64 de 500 KB en JSON se parsea ~2-3× más lento que un endpoint binario equivalente.
• Como medida de seguridad: Base64 no es cifrado — cualquiera puede decodificarlo. Usa AES-GCM o similar para confidencialidad.
• BLOBs de base de datos: almacena bytes crudos como BLOB/BYTEA, no texto Base64, para ahorrar 33 % de almacenamiento y evitar viajes de ida y vuelta de codificar/decodificar.

JWT (RFC 7515) y OAuth PKCE (RFC 7636) usan ambos Base64 URL-safe sin padding, a menudo llamado base64url. Para producirlo en esta herramienta: activa las casillas --url-safe y --no-padding, luego codifica tu texto.

Equivalentes programáticos:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

Campos JWT comunes que necesitan base64url: los tres segmentos separados por puntos (header, payload, signature), code_verifier/code_challenge de OAuth PKCE, challenges WebAuthn, claves p256dh/auth de Web Push y parámetros Request.state de Google.

Un bug común es enviar un JWT con Base64 estándar (+/) — las APIs lo rechazarán como malformado porque el + se URL-decodifica a un espacio durante el tránsito.

Sí, con una salvedad. Este codificador produce la parte Base64 de una Data URI — la parte después de ;base64,. Para construir una Data URI completa, antepón:

data:<mime-type>;base64,<salida-codificada>

Tipos MIME comunes:
• data:image/png;base64,... — imagen PNG
• data:image/jpeg;base64,... — imagen JPEG
• data:image/svg+xml;base64,... — SVG (o usa data:image/svg+xml;utf8, sin Base64 — normalmente más pequeño)
• data:application/pdf;base64,... — archivo PDF
• data:application/font-woff2;base64,... — embed de fuente
• data:text/plain;charset=utf-8;base64,... — texto envuelto en Base64

Para imágenes y SVG, la herramienta Imagen a Base64 emite la Data URI completa lista para pegar en CSS background-image, <img src="..."> inline o etiquetas <object data="...">.

Aviso de tamaño: las Data URIs mayores de 20-30 KB perjudican el LCP (Largest Contentful Paint) porque el navegador no puede precargarlas — mantén pequeñas las imágenes Base64 inline y prefiere <img> regular con loading="lazy" para activos más grandes.

Sí — nada sale de tu navegador. El codificador se ejecuta enteramente en JavaScript usando las APIs nativas btoa(), TextEncoder y FileReader. No hay llamadas de red sobre el contenido de entrada, sin telemetría, sin logs, sin analítica de terceros sobre lo que codificas. Puedes abrir la pestaña Red en DevTools mientras codificas y observar cero solicitudes relacionadas.

Sin embargo, Base64 no es cifrado — es una codificación reversible, y cualquiera con la salida puede decodificarla. Por lo tanto:
• No pegues secretos de producción en chat, capturas o logs ni siquiera en forma codificada.
• Para HTTP Basic Auth, la cabecera Base64 Authorization: Basic solo es segura sobre TLS (HTTPS). Sobre HTTP en texto plano, es trivialmente interceptable.
• Para confidencialidad real, usa AES-GCM, age, sops o un KMS — luego codifica el texto cifrado en Base64 para el transporte si es necesario.

Para políticas estrictas de exfiltración de datos, guarda esta página offline (Cmd/Ctrl + S). El codificador funciona totalmente aislado tras una carga, ya que no hay dependencia del servidor.

El codificador admite archivos de hasta 100 MB mediante el límite estricto en el manejador de archivos — suficiente para la mayoría de imágenes, PDFs, archivos ZIP e incluso vídeos cortos. Objetivos de rendimiento:

• < 1 MB: la codificación completa en <50 ms, sin congelación de UI.
• 1 – 10 MB: 100-500 ms dependiendo de CPU. El navegador permanece receptivo porque codificamos en bloques de 32 KB.
• 10 – 100 MB: 2-15 segundos. El área de salida puede retrasarse ligeramente al pegar/desplazar cadenas Base64 tan grandes. Considera descargar la salida como archivo .txt desde DevTools si lo necesitas.
• > 100 MB: bloqueado — la sobrecarga de memoria del navegador (bytes de entrada + cadena binaria + cadena Base64 ≈ 3-4× el tamaño del archivo) arriesga bloqueos de pestaña. Usa:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

Para flujos de trabajo de streaming/multi-GB, consulta codificar archivos grandes a Base64 para un enfoque por bloques con Node.js/Python que evita cargar todo en memoria.

Este codificador usa UTF-8, la misma codificación utilizada por la web moderna, JSON, Linux, macOS y casi todos los lenguajes de programación por defecto. Bajo el capó, el texto pasa por new TextEncoder().encode(input), que siempre produce bytes UTF-8, y solo entonces se codifica en Base64.

Por qué esto importa: la antigua función JavaScript btoa() solo maneja Latin-1 y lanza InvalidCharacterError con caracteres como é, 中 o 😀. Nuestro wrapper maneja la conversión UTF-8 por ti, así que emoji, chino, japonés, coreano, árabe, cirílico y cualquier punto de código Unicode se codifican correctamente.

Si necesitas una codificación distinta:
• UTF-16 LE (nativo de Windows): raro — normalmente señal de interop heredado. Usa new TextEncoder({ fatal: true }).encode(s) igualmente y convierte aguas arriba.
• ISO-8859-1 / Latin-1: mapea manualmente los puntos de código 0-255 a bytes antes de codificar.
• GB18030, Shift_JIS, EUC-KR: usa una biblioteca como iconv-lite en Node.js para transcodificar primero.

Una sutileza engañosa: si tus datos de origen ya están en una codificación no UTF-8 (p. ej. leyendo un volcado MySQL heredado), decodifícalos primero con el códec correcto, luego re-codifica a UTF-8 antes de Base64 — de lo contrario, el Base64 decodificado preservará el mojibake.