¿Qué estándar Base64 sigue la herramienta?

RFC 4648 (Simon Josefsson, IETF octubre de 2006, Standards Track) — la especificación canónica actual de Base64, deja obsoleto RFC 3548 de julio de 2003. El codificador usa FileReader.readAsDataURL() según la especificación W3C File API (w3c.github.io/FileAPI), referenciada desde el WHATWG HTML Living Standard — una API nativa del navegador que lee el archivo origen de forma asíncrona y emite un data URI completo con el MIME detectado automáticamente desde la propiedad `type` del archivo. La primera aparición de Base64 en el IETF fue RFC 989 por John Linn en BBN Communications Corporation (IETF febrero de 1987, PEM Parte I — Procedimientos de Cifrado y Autenticación de Mensajes; obsoletada por RFC 1040 en 1988 y luego por RFC 1113 en 1989), y la especificación canónica previa a RFC 4648 fue RFC 2045 MIME por Freed y Borenstein, IETF noviembre de 1996.

¿Cuál es la sobrecarga de tamaño de Base64 frente al binario crudo?

Exactamente 4/3, o ~33,33% más grande. Cada 3 bytes de origen se codifican como 4 caracteres ASCII del alfabeto de 64 caracteres (A-Z + a-z + 0-9 + + + /), con relleno `=` para alinear la salida a un múltiplo de 4 caracteres según RFC 4648 §4. Para un PNG de 12 KB son ~16 KB de texto Base64; para un JPG de 100 KB son ~133 KB. La sobrecarga es el precio de representar binario en ASCII de 6 bits por carácter.

¿Cuándo debería usar data URI frente a Base64 crudo?

Data URI (forma completa `data:image/ ;base64, ` según RFC 2397, Larry Masinter, Xerox Corporation, IETF agosto de 1998 Standards Track) cuando incrustas directamente en HTML ` ` o CSS `background-image: url(data:...)` — los navegadores analizan el prefijo para conocer el MIME. Base64 crudo (solo la carga útil) cuando el consumidor ya conoce el MIME por contexto: campos de API JSON, protocolos personalizados, archivos de configuración, pruebas. La herramienta expone ambos mediante botones de copia separados.

¿Cuándo debería evitar incrustar una imagen como Base64?

Archivos grandes (>10 KB crudos es la regla práctica habitual). La sobrecarga de tamaño de ~33% + la falta de almacenamiento en caché (el data URI no puede almacenarse en caché por el navegador como sí podría un archivo independiente; ha de volver a descargarse junto con el documento padre cada vez) suelen superar la petición HTTP ahorrada. Para iconos pequeños, logos, gráficos decorativos, favicons o adjuntos de correo de un solo uso, incrustar es una ganancia neta. Para fotos grandes o recursos reutilizados entre páginas, sirve como archivos normales.

No. FileReader.readAsDataURL() del W3C File API se ejecuta enteramente en el navegador. El archivo se lee desde tu disco local a la memoria de la página y se codifica en Base64 de forma síncrona en JavaScript — no hay llamada fetch(), no hay XHR, no hay baliza de analítica con los bytes del archivo. La cadena codificada existe solo en tu pestaña; nunca sale de tu dispositivo.

Codificador de Imagen a Base64 online — RFC 4648 + RFC 2397 data URI vía W3C File API FileReader.readAsDataURL

Codificador de Imagen a Base64 — RFC 4648 + RFC 2397 data URI vía W3C File API FileReader.readAsDataURL

Codifica cualquier archivo de imagen como cadena ASCII Base64 según RFC 4648 (Simon Josefsson, IETF octubre de 2006 Standards Track — obsoleta RFC 3548 de julio de 2003; la historia de Base64 se remonta a RFC 989 febrero de 1987 y RFC 2045 MIME noviembre de 1996) y un data URI completo según RFC 2397 (Larry Masinter, Xerox Corporation, IETF agosto de 1998 Standards Track — el esquema de URL `data:[<mediatype>][;base64],<data>`). La codificación corre localmente vía FileReader.readAsDataURL() según la especificación W3C File API (w3c.github.io/FileAPI), referenciada desde WHATWG HTML Living Standard — una API de navegador nativa que lee el archivo origen asíncronamente y emite una URL completa `data:image/<mime>;base64,<payload>` donde el MIME se autodetecta desde la propiedad type del archivo. La herramienta expone ambas formas vía botones de copia separados: el data URI COMPLETO (`data:image/png;base64,iVBORw0KGgoAAAA...`) para incrustación directa en atributos HTML `<img src='...'>` o CSS `background-image: url(data:...)`, Y la carga útil Base64 CRUDA (todo lo que viene después de la coma) para consumidores que ya conocen el tipo MIME (cargas JSON de API, archivos de configuración, protocolos personalizados). Base64 expande binario exactamente 4/3 (~33%): cada 3 bytes de binario origen se convierten en 4 caracteres ASCII del alfabeto de 64 caracteres (A-Z + a-z + 0-9 + + + /), con relleno `=` al múltiplo más cercano de 4. Los archivos nunca salen del dispositivo.

Relacionado: Base64 a Imagen Info de Imagen Comprimir Imagen PNG a JPG JPG a PNG WebP a JPG

Cómo codificar una imagen como Base64

Arrastra tu imagen a la herramienta o haz clic para seleccionarla. La File API del navegador expone los datos binarios + el tipo MIME a una instancia FileReader (W3C File API).
La herramienta llama FileReader.readAsDataURL() — una API de navegador nativa que lee el archivo asíncronamente y emite una URL completa `data:image/<mime>;base64,<payload>` cuando se dispara el callback `onload`.
Elige qué forma necesitas desde los dos botones de copia: el data URI COMPLETO (para HTML `<img src='data:image/png;base64,iVBOR...'>` o CSS `background-image: url(data:...)`) O la carga útil Base64 CRUDA (para cuerpos JSON de API + archivos de configuración que ya conocen el tipo MIME).
Pulsa Copiar en la forma elegida para llevar la cadena al portapapeles vía navigator.clipboard.writeText(). El botón Copiar confirma con un icono breve de check durante 2 segundos.
Pega la cadena en tu contexto objetivo. El archivo original queda intacto en el disco — los archivos nunca salen del dispositivo.

Casos de uso comunes

Incrustar iconos / logos / gráficos decorativos pequeños directamente en HTML o CSS para eliminar peticiones HTTP separadas y reducir los RTT de bloqueo de renderizado en la carga inicial de página.
Incrustar una imagen dentro de una carga JSON de API donde la subida binaria multipart no esté admitida (común en funciones serverless y en cuerpos de petición de edge workers).
Entregar una demo HTML monolítica autocontenida, prototipo o prueba de concepto que lleve sus propios recursos de imagen sin dependencias externas.
Pegar un logo en una plantilla de correo donde el cliente del destinatario bloquea la carga externa de imágenes (común en Gmail, Outlook, pasarelas de correo corporativas).
Generar data URIs para vistas previas de sprites SVG, incrustación de favicons vía `<link rel='icon' href='data:...'>`, o documentación estilo storyboard / Figma de sistemas de diseño.

Preguntas frecuentes

¿Base64 es siempre buena idea para imágenes?

No. Base64 añade exactamente 4/3 (~33%) de sobrecarga de tamaño según RFC 4648 — cada 3 bytes origen se convierten en 4 caracteres ASCII. El data URI tampoco se puede cachear por el navegador como sí puede una URL de recurso separada (cada página que incrusta la misma imagen envía su propia copia). Para imágenes por encima de ~10 KB en crudo, los ahorros por eliminar peticiones raramente superan la sobrecarga de tamaño + la no amigabilidad con caché. Usa Base64 para: iconos pequeños (<2 KB), logos (<5 KB), imágenes incrustadas en correo, cargas JSON de API, demos HTML monolíticas. Sirve como recursos HTTP regulares para: fotos más grandes, imágenes usadas repetidamente, cualquier cosa que se beneficie del cacheado HTTP.

¿Qué forma pego en HTML o CSS?

El data URI completo (empieza con `data:image/...;base64,`). El prefijo `data:` es parte del esquema URL RFC 2397 (Masinter, IETF agosto de 1998) que dice al navegador cómo interpretar la carga útil como datos de imagen en línea. Ejemplos: `<img src='data:image/png;base64,iVBOR...'>` en HTML, o `background-image: url(data:image/png;base64,iVBOR...)` en CSS. La carga útil Base64 cruda (sin el prefijo `data:image/...;base64,`) solo es útil cuando el consumidor ya conoce el tipo MIME — cuerpos JSON de API, archivos de configuración, protocolos binarios personalizados.

¿Codificar cambia la calidad de imagen?

No. Base64 según RFC 4648 es una codificación texto-ASCII sin pérdida byte a byte — codificar después decodificar produce una imagen byte a byte idéntica al original. La forma codificada es solo una representación de texto distinta de los mismos bytes binarios; el formato de imagen subyacente (PNG, JPEG, WebP, etc.) y sus ajustes de calidad no se ven afectados. El único 'coste' es la sobrecarga de ~33% de tamaño por representar 3 bytes binarios como 4 caracteres ASCII.

¿Qué tipos MIME admite la herramienta?

Cualquier tipo MIME que el navegador autodetecte desde la propiedad File.type — image/png, image/jpeg, image/webp, image/avif, image/gif, image/svg+xml, image/x-icon, image/bmp, image/tiff (donde el navegador lo admita), etc. FileReader.readAsDataURL del W3C File API emite el data URI con cualquier MIME que la File API reporte para el archivo origen.

¿Se sube mi imagen?

No. La codificación corre del lado cliente vía FileReader.readAsDataURL() del W3C File API — el archivo nunca llega a un servidor. La pestaña Network de DevTools muestra cero peticiones de subida durante la codificación. Las cadenas Base64 + data URI viven solo en la memoria de tu navegador + portapapeles.

Pipeline RFC 4648 Base64 + RFC 2397 data URI + FileReader.readAsDataURL (W3C File API)

El pipeline de codificación usa APIs de navegador nativas de extremo a extremo: el archivo origen entra vía la W3C File API (w3c.github.io/FileAPI, referenciada desde WHATWG HTML Living Standard), pasa por FileReader.readAsDataURL() según la misma spec (una instancia `FileReader` con un callback `onload` que se dispara cuando `reader.result` contiene la cadena data URI completa), después la herramienta divide el resultado en la primera coma para exponer ambas formas: el data URI (`data:image/png;base64,iVBORw0KGgo...`) Y la carga útil Base64 cruda (`iVBORw0KGgo...`). La codificación Base64 en sí sigue RFC 4648 (Simon Josefsson, IETF octubre de 2006, Standards Track, obsoleta RFC 3548 julio de 2003) — cada 3 bytes origen se codifican como 4 caracteres ASCII del alfabeto de 64 caracteres [A-Za-z0-9+/], con relleno `=` para alinear a un múltiplo de 4 caracteres; esto produce una expansión exacta de tamaño de 4/3 (~33,33% de sobrecarga) respecto a la entrada binaria cruda. La historia de Base64 en IETF se remonta a RFC 989 (Linn, BBN Communications Corporation, IETF febrero de 1987, PEM Parte I; obsoletada por RFC 1040 1988 después RFC 1113 1989) y RFC 2045 (Freed y Borenstein, IETF noviembre de 1996, MIME Parte Uno). El esquema data URI es RFC 2397 (Larry Masinter, Xerox Corporation, IETF agosto de 1998, Standards Track) — define la sintaxis de URL `data:[<mediatype>][;base64],<data>` con la extensión `;base64` distinguible de un parámetro content-type por la ausencia de un signo `=` siguiente. El MIME por defecto si se omite es `text/plain;charset=US-ASCII` según el RFC, pero para datos de imagen el MIME siempre es explícito (image/png, image/jpeg, image/webp, image/avif, image/gif, image/svg+xml — aunque ver la herramienta base64-to-image para notas de endurecimiento XSS de SVG). Casos de uso prácticos: incrustar imágenes pequeñas (iconos, logos, favicons, gráficos decorativos) directamente en HTML/CSS para eliminar peticiones HTTP + reducir los RTT de bloqueo de renderizado; incrustar imágenes en cargas JSON de API donde la subida binaria multipart no esté admitida; entregar demos HTML monolíticas autocontenidas de un solo archivo con sus propios recursos de imagen; pegar logos en plantillas de correo donde la carga externa de imágenes está bloqueada. Anti-patrón: las imágenes grandes (>10 KB en crudo) normalmente no deberían incrustarse en Base64 porque la sobrecarga de ~33% de tamaño + la no amigabilidad con caché (el data URI no se puede cachear por el navegador como un archivo separado sí puede) superan la petición HTTP ahorrada — para esas, sirve como recurso regular.

Codificación Base64 según RFC 4648 (Josefsson, IETF octubre de 2006, Standards Track) — obsoleta RFC 3548 julio de 2003; historia Base64 RFC 989 (Linn, BBNCC, febrero de 1987) + RFC 2045 noviembre de 1996
Data URI según RFC 2397 (Masinter, Xerox, IETF agosto de 1998, Standards Track) — sintaxis URL `data:[<mediatype>][;base64],<data>`
API de navegador nativa FileReader.readAsDataURL() según W3C File API (w3c.github.io/FileAPI), referenciada desde WHATWG HTML Living Standard
Produce AMBAS formas: data URI completo (para `<img src='...'>` + CSS background-image) Y carga útil Base64 cruda (para JSON API + protocolos personalizados)
Copia al portapapeles con un clic vía navigator.clipboard.writeText() para ambas formas
Muestra las longitudes de caracteres de Base64 + data URI como referencia (data URI = data:image/<mime>;base64, prefijo + carga útil cruda)
Sobrecarga de ~33% según RFC 4648 (4 caracteres ASCII por 3 bytes origen) — anti-patrón: imágenes grandes (>10 KB crudo) no deberían incrustarse
En el navegador vía FileReader del W3C File API — sin subida, sin servidor, MIME autodetectado desde File.type

Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).

Fuentes (7)

Josefsson, S. (SJD) (2006). The Base16, Base32, and Base64 Data Encodings. RFC 4648, IETF (October 2006, Standards Track) — obsoletes RFC 3548 (July 2003); canonical Base64 specification (alphabet A-Z + a-z + 0-9 + + + /, padding `=`, 4-to-3 ASCII-to-byte expansion); §4 defines standard Base64.
Masinter, L. (Xerox Corporation) (1998). The 'data' URL scheme. RFC 2397, IETF (August 1998, Standards Track) — defines `data:[<mediatype>][;base64],<data>` URL syntax (parameters live inside mediatype per BNF); default MIME `text/plain;charset=US-ASCII`; `;base64` extension distinguishable from content-type parameter by absence of following `=`.
Freed, N. (Innosoft) & Borenstein, N. (First Virtual Holdings) (1996). Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, IETF (November 1996, Standards Track) — §6.8 defines pre-RFC 4648 canonical Base64 for MIME; precedes RFC 3548 (2003) and RFC 4648 (2006).
Linn, J. (BBN Communications Corporation) (1987). Privacy Enhancement for Internet Electronic Mail: Part I — Message Encipherment and Authentication Procedures. RFC 989, IETF (February 1987) — first IETF appearance of Base64 encoding for PEM message bodies; obsoleted by RFC 1040 (January 1988) then RFC 1113 (August 1989); Part III algorithms specified separately in RFC 1115 (Linn, DEC, August 1989); superseded by RFC 4648.
W3C Web Applications Working Group (live). File API — FileReader.readAsDataURL(). w3c.github.io/FileAPI — W3C Working Draft; FileReader.readAsDataURL() asynchronously reads a File/Blob and emits `data:<MIME>;base64,<payload>` URL via `result` on the `load` event with MIME from the file's `type` property.
W3C Web Applications Working Group (live). File API — File + Blob + FileReader interfaces. w3c.github.io/FileAPI — File interface inherits Blob; FileReader provides readAsArrayBuffer/readAsText/readAsDataURL with onload/onerror callbacks; referenced from WHATWG HTML Living Standard.
WHATWG (live). HTML Living Standard — File API references and integration. html.spec.whatwg.org — references the W3C File API spec for File/Blob/FileReader interfaces used across the platform.

Son las especificaciones del W3C, ISO/IEC, ITU-T e IETF que la herramienta implementa o sobre las que se apoya. Localízalas en w3.org, iso.org, itu.int o datatracker.ietf.org.

Patrocinado

Por Marco B. · Última verificación mayo 2026 — corre en tu navegador