Skip to content

Decodificador Base64 a Imagen online

En el navegador — sin subida
Última verificación mayo 2026 — corre en tu navegador

Decodificador de Base64 a Imagen — RFC 4648 + RFC 2397 vía window.atob con bloqueo XSS de SVG

Decodifica cualquier carga útil Base64 en ASCII o data URI completo de vuelta a un archivo de imagen binario descargable según RFC 4648 (Simon Josefsson, IETF octubre de 2006, Standards Track) y RFC 2397 (Larry Masinter, Xerox Corporation, IETF agosto de 1998, Standards Track). El decodificador se ejecuta en tu navegador mediante window.atob() (WHATWG HTML Living Standard, html.spec.whatwg.org/multipage/webappapis.html, definido en Web IDL sobre el mixin WindowOrWorkerGlobalScope), que revierte la expansión Base64 de 4 caracteres ASCII a 3 bytes y recupera los bytes binarios originales. La herramienta detecta el tipo MIME desde un prefijo data URI mediante la expresión regular `^data:(image/\w+);base64,` y lo recorta antes de llamar a atob; si no hay prefijo, la carga útil se decodifica como Base64 crudo y se trata como image/png por defecto. Los bytes decodificados pasan por un buffer Uint8Array (mediante charCodeAt sobre la cadena de salida de atob según la especificación WHATWG ArrayBuffer + TypedArray) a un Blob, y luego se genera una URL de blob con URL.createObjectURL() para el panel de vista previa y el botón de descarga. ENDURECIMIENTO DE SEGURIDAD: la herramienta RECHAZA explícitamente image/svg+xml aunque es un tipo MIME de imagen válido — los documentos SVG pueden contener elementos `<script>` y atributos de manejador de evento en línea (onload, onclick, onerror), y representar un SVG mediante una URL de blob ejecuta esos scripts en el contexto del MISMO ORIGEN de openimages.app, idéntico a abrir un archivo HTML crudo. El aviso divulgado de referencia para este vector es CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw (PrivateBin, XSS de SVG vía URL de blob en vista previa de adjunto, abril de 2022); el patrón XSS-SVG en subidas de usuario es una clase recurrente documentada en avisos y análisis (research.securitum.com Bentkowski 2019; antipatrón `DomSanitizer.bypassSecurityTrustResourceUrl` de Angular en angular.dev/best-practices/security). El bloqueo es defensa en profundidad intencional — convierte fuentes SVG mediante un renderizador del lado del servidor, no una URL de blob del navegador.

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

Cómo decodificar Base64 a un archivo de imagen descargable

  1. Copia la cadena Base64 O el data URI completo `data:image/<mime>;base64,...` desde tu fuente (CSS, carga útil de API JSON, plantilla de correo, archivo de configuración, registro de depuración).
  2. Pega el valor en el área de texto de entrada. Ambas formas funcionan: la expresión regular `^data:(image/\w+);base64,` detecta el MIME automáticamente y recorta el prefijo; el Base64 crudo sin prefijo se decodifica como image/png por defecto.
  3. La herramienta llama a window.atob() según WHATWG para revertir la expansión Base64 (4 caracteres ASCII → 3 bytes), luego construye un Uint8Array y lo envuelve en un Blob con el MIME detectado.
  4. Se genera una URL de blob mediante URL.createObjectURL() y se muestra en el panel de vista previa. Si el MIME detectado es image/svg+xml, la decodificación se detiene con un error — el SVG ejecutaría scripts incrustados en el origen de la página (consulta las notas de seguridad).
  5. Pulsa Descargar para guardar los bytes decodificados como archivo binario real con la extensión correcta (.png, .jpg, .gif, .webp, .avif). La cadena Base64 original se reconstruye byte a byte — Base64 es una codificación textual sin pérdida.

Casos de uso comunes

  • Recuperar un PNG/JPG/WebP real desde una cadena `data:image/...;base64,...` copiada de CSS, una respuesta de API JSON, una plantilla de correo o una instantánea de estado guardada.
  • Inspeccionar qué contiene realmente un píxel de seguimiento en línea, un favicon codificado o una imagen de firma antes de confiar en ello o de enviarlo.
  • Depurar respuestas de API que devuelven imágenes como cadenas Base64 en lugar de multipart binario — pega la carga útil, mira la imagen.
  • Extraer adjuntos incrustados de plantillas de correo HTML o demos HTML de un solo archivo donde la imagen está en línea como data URI.
  • Verificar que el lado del codificador produjo un ciclo de ida y vuelta válido — codifica una imagen en otro sitio, pega el resultado aquí, confirma que los bytes vuelven a la misma imagen.

Preguntas frecuentes

¿Por qué la herramienta bloquea image/svg+xml?

SVG es XML y puede contener elementos `<script>` y manejadores de evento en línea (onload, onclick, onerror, onmouseover). Cuando el decodificador construye un Blob con tipo image/svg+xml y llama a URL.createObjectURL(), la URL de blob resultante hereda el origen de openimages.app. Cargar dicha URL mediante `<img>` o navegar hacia ella ejecuta el JavaScript incrustado en contexto del mismo origen — exactamente la misma clase de riesgo que abrir un archivo HTML crudo con scripts en línea. El aviso divulgado de referencia es CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw (PrivateBin, XSS de SVG vía URL de blob en vista previa de adjunto, abril de 2022); la clase XSS-SVG en subidas de usuario está documentada en análisis de seguridad (research.securitum.com Bentkowski 2019) y en el antipatrón `DomSanitizer.bypassSecurityTrustResourceUrl` de Angular (angular.dev/best-practices/security). El bloqueo es defensa en profundidad intencional. Para convertir SVG, usa un renderizador del lado del servidor que no comparta su origen con cookies sensibles o almacenamiento, o utiliza una herramienta de imagen de escritorio.

¿Cuál es la diferencia entre Base64 crudo y un data URI?

Un data URI es una cadena Base64 envuelta en el prefijo URI de RFC 2397 `data:image/<mime>;base64,<carga>`. El prefijo declara el MIME explícitamente para que el software receptor (navegadores, bibliotecas de imagen, el decodificador aquí) sepa cómo representar o guardar los bytes. El Base64 crudo es solo la carga útil — los mismos caracteres sin el prefijo — y requiere que el consumidor ya conozca o adivine el MIME. La herramienta ejecuta la expresión regular `^data:(image/\w+);base64,` para detectarlo automáticamente; si coincide, se usa el MIME capturado y se recorta el prefijo; si no coincide, la carga se trata como image/png por defecto.

¿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 decodificador usa window.atob() según el WHATWG HTML Living Standard (html.spec.whatwg.org/multipage/webappapis.html, definido en Web IDL sobre el mixin WindowOrWorkerGlobalScope), que implementa la variante tolerante de RFC 4648 (espacios admitidos, relleno `=` opcional en algunos casos). 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.

¿La decodificación pierde calidad?

No. Base64 es una representación ASCII sin pérdida de los bytes binarios exactos — cada 4 caracteres ASCII se revierten a exactamente 3 bytes de origen (RFC 4648 §4). El decodificador produce una copia byte a byte idéntica del archivo originalmente codificado. Los únicos modos de fallo son daño al copiar (caracteres que faltan, finales de línea CR/LF mezclados, espacios extra fuera del alfabeto tolerante) y datos binarios no de imagen — atob lanza InvalidCharacterError ante una entrada mal formada.

¿Se suben mis datos a algún sitio?

No. window.atob() es una API nativa síncrona del navegador que se ejecuta enteramente en el contexto JavaScript de la página. La cadena Base64 nunca sale de tu dispositivo — no hay llamada fetch(), no hay XHR, no hay baliza de analítica con la carga útil. El Blob decodificado existe solo en la memoria de tu pestaña; la URL de blob es local a tu navegador y se revoca al cerrar la página.

Decodificación atob() RFC 4648 + análisis del prefijo data URI RFC 2397 + rechazo XSS de SVG

El pipeline analiza prefijos de data URI opcionales según RFC 2397 (Larry Masinter, Xerox Corporation, IETF agosto de 1998, Standards Track — define el esquema URL `data:[<mediatype>][;base64],<data>`), luego llama a window.atob() según el WHATWG HTML Living Standard (html.spec.whatwg.org/multipage/webappapis.html#atob, definido en Web IDL sobre el mixin WindowOrWorkerGlobalScope desde la especificación WebIDL original — atob es un inverso síncrono de Base64 sobre un alfabeto Base64 tolerante [A-Za-z0-9+/=] con espacios admitidos, lanza InvalidCharacterError ante una entrada mal formada según la especificación). La salida de atob es una cadena JavaScript donde la unidad de código UTF-16 (0-255) de cada carácter representa un byte decodificado; la herramienta itera con charCodeAt para poblar un Uint8Array (especificación TypedArray de WHATWG), lo envuelve en un Blob con el MIME detectado (W3C File API), y genera una URL de blob mediante URL.createObjectURL() (W3C File API) para la vista previa y la descarga. El algoritmo Base64 propiamente dicho sigue RFC 4648 (Simon Josefsson, IETF octubre de 2006, Standards Track, deja obsoleto RFC 3548 de julio de 2003; 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; la especificación canónica previa a RFC 4648 fue RFC 2045 MIME por Freed y Borenstein, IETF noviembre de 1996) — el alfabeto de 64 caracteres A-Z + a-z + 0-9 + + + / con relleno `=` produce exactamente 4/3 caracteres ASCII por cada 3 bytes de origen. Detección de MIME: la herramienta ejecuta `^data:(image/\w+);base64,` sobre la entrada — si coincide, se usa el MIME capturado y se recorta el prefijo; si no coincide, la carga útil se trata como Base64 crudo con image/png como tipo por defecto. SEGURIDAD: image/svg+xml es RECHAZADO con un mensaje de error. La razón: SVG es XML, puede contener `<script>` y manejadores de evento en JavaScript (onload, onclick, onmouseover), y una URL de blob producida por URL.createObjectURL() hereda el origen de la página (openimages.app) — abrir o cargar mediante `<img src>` dicha URL de blob con tipo image/svg+xml ejecuta el script incrustado en contexto del mismo origen según la especificación SVG del W3C y la semántica de fetch + URL de blob de WHATWG. El aviso divulgado de referencia para este vector exacto es CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw (PrivateBin, XSS de SVG vía URL de blob en vista previa de adjunto, abril de 2022); la clase XSS-SVG en subidas de usuario aparece en análisis de seguridad (research.securitum.com Bentkowski 2019) y en el antipatrón `DomSanitizer.bypassSecurityTrustResourceUrl` de Angular (angular.dev/best-practices/security). El rechazo es defensa en profundidad deliberada; la comprobación se ejecuta tras extraer el prefijo, por lo que un actor malicioso que prepare una carga útil SVG no puede eludir la expresión regular re-prefijando el MIME. Convierte SVG mediante un pipeline de renderizado del lado del servidor que no comparta el origen con cookies sensibles o almacenamiento.

  • Decodificación Base64 según RFC 4648 (Josefsson, IETF octubre de 2006, Standards Track) — deja obsoleto RFC 3548 julio de 2003; historia de Base64 RFC 989 (Linn, BBNCC, febrero de 1987) + RFC 2045 noviembre de 1996
  • Análisis de data URI según RFC 2397 (Masinter, Xerox Corporation, IETF agosto de 1998, Standards Track) — esquema URL `data:[<mediatype>][;base64],<data>`
  • API nativa del navegador window.atob() de WHATWG — html.spec.whatwg.org/multipage/webappapis.html sobre el mixin WindowOrWorkerGlobalScope, alfabeto Base64 tolerante, InvalidCharacterError ante entrada mal formada
  • Detección automática de MIME mediante la expresión regular `^data:(image/\w+);base64,` — recorta el prefijo, captura el MIME; recurre a image/png cuando no hay prefijo
  • Pipeline: cadena de atob() → bucle charCodeAt → Uint8Array → Blob → URL de blob de URL.createObjectURL() para vista previa y descarga (TypedArray de WHATWG + File API del W3C)
  • SEGURIDAD: image/svg+xml es RECHAZADO — SVG puede llevar `<script>` y manejadores de evento en línea (onload/onclick); las URL de blob heredan el origen openimages.app, ejecutando los scripts en contexto del mismo origen
  • Aviso divulgado de referencia: CVE-2022-24833 / GHSA-cqcc-mm6x-vmvw (PrivateBin, XSS de SVG vía URL de blob en vista previa de adjunto, abril de 2022); el patrón se repite en análisis XSS-SVG de subidas de usuario (research.securitum.com Bentkowski 2019; antipatrón DomSanitizer.bypassSecurityTrustResourceUrl de Angular)
  • Nativo del navegador — sin SDK, sin subida, sin ida y vuelta al servidor; la carga útil permanece en tu pestaña

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

Fuentes (10)
  • Josefsson, S. (SJD) (2006). The Base16, Base32, and Base64 Data Encodings. RFC 4648, IETF (October 2006, Standards Track) — obsoletes RFC 3548 (July 2003); §4 standard Base64 with forgiving decode (whitespace tolerated).
  • Masinter, L. (Xerox Corporation) (1998). The 'data' URL scheme. RFC 2397, IETF (August 1998, Standards Track) — `data:[<mediatype>][;base64],<data>` URL syntax parsed by the tool's `^data:(image/\w+);base64,` regex.
  • 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) — pre-RFC 4648 canonical Base64 spec; §6.8 defines the 64-character alphabet and `=` padding.
  • 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; obsoleted by RFC 1040 (1988) then RFC 1113 (1989); superseded by RFC 4648.
  • WHATWG (live). HTML Living Standard — window.atob(). html.spec.whatwg.org/multipage/webappapis.html#atob — synchronous Base64 decode on WindowOrWorkerGlobalScope mixin; forgiving alphabet tolerates whitespace; throws InvalidCharacterError on malformed input.
  • WHATWG (live). HTML Living Standard — URL.createObjectURL() blob URL semantics. url.spec.whatwg.org + html.spec.whatwg.org — blob URLs inherit the page's origin; loading a blob URL with image/svg+xml MIME executes embedded scripts in same-origin context.
  • W3C SVG Working Group (2018). Scalable Vector Graphics (SVG) 2. W3C Candidate Recommendation 4 October 2018 — SVG documents support `<script>` elements and inline event-handler attributes (onload, onclick, onerror, onmouseover); scripts execute in document's origin.
  • Bentkowski, M. (Securitum) (2019). Do you allow to load SVG files? You have XSS!. research.securitum.com — primary-source write-up of SVG-via-user-upload XSS class; documents the `<script>` + `onload`/`onclick`/foreignObject vectors that justify the SVG MIME block.
  • PrivateBin maintainers (2022). GHSA-cqcc-mm6x-vmvw / CVE-2022-24833 — SVG attachment preview blob URL XSS. github.com/PrivateBin/PrivateBin/security/advisories/GHSA-cqcc-mm6x-vmvw + privatebin.info/reports/vulnerability-2022-04-09.html — the canonical disclosed advisory for the SVG-via-`URL.createObjectURL` same-origin XSS vector this tool defends against.
  • Angular maintainers (live). Angular Security Guide — DomSanitizer.bypassSecurityTrustResourceUrl misuse. angular.dev/best-practices/security — documents the SVG-resource-URL antipattern where bypassing the sanitiser on untrusted SVG sources permits same-origin script execution.

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 ·